moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

Initial draft of SRV records for XMPP over TLS

Browse Source
This commit is contained in:
Travis Burtrum 2015-11-04 22:33:25 -05:00
parent b3ea9bd059
commit c9295aaaa1
1 changed files with 80 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
inbox/tls-srv.xml Normal file
View File

@ -0,0 +1,80 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY rfc7301 "<span class='ref'><link url='https://tools.ietf.org/html/rfc7301'>RFC 7301</link></span> <note>RFC 7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension &lt;<link url='https://tools.ietf.org/html/rfc7301'>https://tools.ietf.org/html/rfc7301</link>&gt;.</note>" >
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>SRV records for XMPP over TLS</title>
<abstract>This specification defines a procedure to look up _tls SRV records in addition to _tcp and mix weights/priorities.</abstract>
<legal>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2014 by the XMPP Standards Foundation (XSF).</copyright>
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the &quot;Specification&quot;), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.</permissions>
<warranty>## NOTE WELL: This Specification is provided on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
<liability>In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.</liability>
<conformance>This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at &lt;<link url='http://xmpp.org/extensions/ipr-policy.shtml'>http://xmpp.org/extensions/ipr-policy.shtml</link>&gt; or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).</conformance>
</legal>
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>RFC 2782</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Travis</firstname>
<surname>Burtrum</surname>
<email>travis@burtrum.org</email>
<jid>travis@burtrum.org</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2015-10-31</date>
<initials>psa</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&xmppcore; specifies the use of _tcp SRV records as the method of discovering how to connect to an XMPP server. This XEP extends that to include _tls SRV records and combine priorities and weights as if they were a single SRV record. Applied to both xmpp-client and xmpp-server SRV records, this provides the opportunity to connect to XMPP servers with at least equal and perhaps increased security and privacy over using STARTTLS. It also provides an easy way for clients to bypass restrictive firewalls that only allow HTTPS, and for servers to host multiple protocols/services on a single port.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The following format for DNS SRV resource records is specified in &rfc2782;:</p>
<code><![CDATA[
_service._proto.name. TTL class SRV priority weight port target.
]]></code>
<p><cite>XMPP Core</cite> defines SRV records only where 'proto' is 'tcp'. This document specifies to additionally look up the same records where 'proto' is 'tls'. This document specifies that the following additional rules apply:</p>
<ol>
<li>Treat both 'tcp' and 'tls' records as the same record with regard to connection order as specified by <cite>RFC 2782</cite>, in that all priorities and weights are mixed. (so the server operator can decide if they would rather clients connect to tcp with STARTTLS or just with TLS directly)</li>
<li>Where 'proto' is 'tls' the client or server MUST connect with TLS enabled.</li>
<li>Where 'proto' is 'tcp' the client or server MUST NOT connect with TLS enabled, connection method is unchanged from <cite>XMPP Core</cite>.</li>
<li>TLS certificates MUST be validated the same way as for STARTTLS. (ie, as specified in <cite>XMPP Core</cite>).</li>
<li>STARTTLS MUST NOT be used over TLS connections.</li>
<li>Client or server SHOULD set SNI TLS extension to the host in the SRV record.</li>
<li>Client or server SHOULD set the ALPN (&rfc7301;) TLS extension.</li>
<li>When ALPN is used protocol MUST be 'xmpp-client' where 'xmpp-client' is the SRV 'service'.</li>
<li>When ALPN is used protocol MUST be 'xmpp-server' where 'xmpp-server' is the SRV 'service'.</li>
</ol>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<p>For server operators, this provides a way to host multiple services on the same port, especially when SNI or ALPN extensions are used. Servers could even host xmpp-client and xmpp-server services on the same TLS port. For clients, this provides a virtually no overhead way to bypass restrictive firewalls that only allow HTTP over port 80 and HTTPS over port 443, as xmpp-over-tls is indistinguishable from http-over-tls.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>The only overhead is the single additional SRV lookup. All clients that support STARTTLS already have support for TLS-over-tcp. </p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>TLS provides AT LEAST the same level of security as STARTTLS, and possibly more privacy as using STARTTLS leaks that the underlying protocol is XMPP, while any TLS stream should be indistinguishable from any other TLS stream. All security setup and certificate validation code should be shared between the STARTTLS and TLS logic as well.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>ALPN (<cite>RFC 7301</cite>) requires registration of the new Protocol IDs, 'xmpp-client' and 'xmpp-server', specified in this document. The registry is currently located <link url='https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids'>here</link></p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>There are no XMPP Registrar Considerations.</p>
</section1>
</xep>