-
Notifications
You must be signed in to change notification settings - Fork 121
/
xep-0368.xml
153 lines (149 loc) · 9.32 KB
/
xep-0368.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?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 xmpps-client/xmpps-server SRV records (for direct TLS connections) in addition to xmpp-client/xmpp-server and mix weights/priorities.</abstract>
&LEGALNOTICE;
<number>0368</number>
<status>Draft</status>
<lastcall>2017-02-22</lastcall>
<lastcall>2017-02-11</lastcall>
<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>1.1.0</version>
<date>2019-08-20</date>
<initials>jsc</initials>
<remark><p>Describe how to fall back if _xmpps-server/_xmpps-client records cannot be found.</p></remark>
</revision>
<revision>
<version>1.0.1</version>
<date>2019-07-15</date>
<initials>Nyco</initials>
<remark><p>Fix trivial 'to' vs. 'two' typo.</p></remark>
</revision>
<revision>
<version>1.0.0</version>
<date>2017-03-09</date>
<initials>XEP Editor (ssw)</initials>
<remark><p>Advance to draft as approved by the XMPP Council.</p></remark>
</revision>
<revision>
<version>0.1.2</version>
<date>2017-02-15</date>
<initials>tjb</initials>
<remark><p>Implement more last call comments, editorial changes, mixing SRV records is now SHOULD.</p></remark>
</revision>
<revision>
<version>0.1.1</version>
<date>2017-02-06</date>
<initials>tjb</initials>
<remark><p>Implement last call comments, editorial changes, SNI is now MUST.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2015-12-15</date>
<initials>XEP Editor (asw)</initials>
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2015-12-15</date>
<initials>tjb</initials>
<remark><p>tls proto to tcp, change service instead. Set SNI correctly.</p></remark>
</revision>
<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 xmpp-client/xmpp-server SRV records as the method of discovering how to connect to an XMPP server. This XEP extends that to include new xmpps-client/xmpps-server SRV records pointing to direct TLS ports and combine priorities and weights as if they were a single SRV record similar to &rfc6186;. It also provides an easy way for clients to bypass restrictive firewalls that only allow HTTPS, for servers to host multiple protocols/services on a single port, and for servers and clients to take advantage of less round trips and existing direct TLS loadbalancers.</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<dl>
<di>
<dt>Direct TLS</dt>
<dd>
Where TLS is attempted immediately on connect to a TCP socket, like how HTTPS works, not like how STARTTLS works with any protocol.
</dd>
</di>
</dl>
</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>&xmppcore; defines SRV records only where 'service' is 'xmpp-client' and 'xmpp-server'. This document specifies two additionally look up records where 'service' is 'xmpps-client' and 'xmpps-server'. This document specifies that the following additional rules apply:</p>
<ol>
<li>Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same record with regard to connection order as specified by &rfc2782;, in that all priorities and weights are mixed. This enables the server operator to decide if they would rather clients connect with STARTTLS or direct TLS. However, clients MAY choose to prefer one type of connection over the other.</li>
<li>Where 'service' starts with 'xmpps-' the client or server MUST connect with direct TLS enabled.</li>
<li>Where 'service' starts with 'xmpp-' the client or server MUST NOT connect with direct TLS enabled, connection method is unchanged from &xmppcore;.</li>
<li>TLS certificates MUST be validated the same way as for STARTTLS. (i.e., as specified in &xmppcore;).</li>
<li>STARTTLS MUST NOT be used over direct TLS connections.</li>
<li>Client or server MUST set SNI TLS extension to the JID's domain part.</li>
<li>Client or server SHOULD set the ALPN (&rfc7301;) TLS extension.</li>
<li>When ALPN is used, the ALPN protocol MUST be '<strong>xmpp-client</strong>', where the SRV service is '<strong>xmpps-client</strong>'.</li>
<li>When ALPN is used, the ALPN protocol MUST be '<strong>xmpp-server</strong>', where the SRV service is '<strong>xmpps-server</strong>'.</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 zero 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 when ALPN is not used. For clients and servers, direct TLS saves round trips vs STARTTLS.</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 direct TLS.</p>
<p>Server operators should not expect multiplexing (via ALPN) to work in all scenarios and therefore should provide additional SRV record(s) that do not require multiplexing (either standard STARTTLS or dedicated direct XMPP-over-TLS). This is a result of relying on ALPN for multiplexing, where ALPN might not be supported by all devices or may be disabled by a user due to privacy reasons.</p>
<p>If the <tt>_xmpps-client</tt> (or <tt>_xmpps-server</tt>) target is set to <tt>.</tt> (dot), this indicates as per &rfc2782; that the service is not provided for the given domain. In this context, this means that Direct TLS is not supported. In this case, the initiating party SHOULD look up <tt>_xmpp-client</tt> (or <tt>_xmpp-server</tt>) records. The initiating party MUST NOT perform A/AAAA fallback as per &rfc6120; (since the service provider has already indicated that the SRV protocol is supported).</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>Direct TLS provides AT LEAST the same level of security as STARTTLS, and more privacy without ALPN as using STARTTLS leaks that the underlying protocol is XMPP, while any direct TLS stream should be indistinguishable from any other direct TLS stream. Direct TLS provides more security than STARTTLS if &rfc7590; is not followed, as it isn't subject to STARTTLS stripping. All security setup and certificate validation code SHOULD be shared between the STARTTLS and direct TLS logic as well. All SRV-based connection methods are subject to DNS modification/stripping/spoofing of SRV records in the absence of DNSSEC.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>ALPN (&rfc7301;) requires registration of new Protocol IDs. This document specifies two Protocol IDs:</p>
<p>
Protocol: XMPP jabber:client namespace<br/>
Identification Sequence:<br/>
0x78 0x6d 0x70 0x70 0x2d 0x63 0x6c 0x69 0x65 0x6e 0x74 ("xmpp-client")<br/>
Reference: [&xep0368;]
</p>
<p>
Protocol: XMPP jabber:server namespace<br/>
Identification Sequence:<br/>
0x78 0x6d 0x70 0x70 0x2d 0x73 0x65 0x72 0x76 0x65 0x72 ("xmpp-server")<br/>
Reference: [&xep0368;]
</p>
<p>The ALPN registry is currently located <link url='https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids'>here</link>.</p>
<p>Issues with direct TLS ports mentioned in &rfc2595; <link url='https://tools.ietf.org/html/rfc2595#section-7'>Section 7</link> do not apply here for these reasons:</p>
<ol>
<li>URL scheme is unchanged.</li>
<li>"Security" is the same between STARTTLS and direct TLS, and post-2014 the general consensus is that no public XMPP server or client should connect without some form of TLS per the <link url='https://github.com/stpeter/manifesto/blob/master/manifesto.txt'>ubiquitous encryption manifesto</link>.</li>
<li>A "Use TLS when available" security model is possible here because the client could fall back to standard STARTTLS SRV records if the server administrator supplies them.</li>
<li>No port numbers are assigned because SRV allows using arbitrary ports at the server administrator's discretion.</li>
</ol>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This document requires no interaction with the ®ISTRAR;.</p>
</section1>
</xep>