Implement last call comments, editorial changes, SNI is now MUST.
&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 TLS ports and combine priorities and weights as if they were a single SRV record. Applied to both xmpps-client and xmpps-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.
+&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. Applied to both xmpps-client and xmpps-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.
+The following format for DNS SRV resource records is specified in &rfc2782;:
@@ -61,28 +78,52 @@XMPP Core defines SRV records only where 'service' is 'xmpp-client' and 'xmpp-server'. This document specifies to additionally look up records where 'service' is 'xmpps-client' and 'xmpps-server'. This document specifies that the following additional rules apply:
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 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.
The only overhead is the single additional SRV lookup. All clients that support STARTTLS already have support for TLS-over-tcp.
-Server operators should not expect multiplexing to work in all scenarios and therefore should provide additional SRV record(s) that do not require multiplexing (either standard STARTTLS or dedicated 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.
+The only overhead is the single additional SRV lookup. All clients that support STARTTLS already have support for direct TLS.
+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.
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 TLS stream should be indistinguishable from any other TLS stream. 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 TLS logic as well.
+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.
ALPN (RFC 7301) requires registration of the new Protocol IDs, 'xmpp-client' and 'xmpp-server', specified in this document. The registry is currently located here
+ALPN (RFC 7301) requires registration of new Protocol IDs. This document specifies two Protocol IDs:
+ +
+Protocol: XMPP jabber:client namespace
+Identification Sequence:
+ 0x78 0x6d 0x70 0x70 0x2d 0x63 0x6c 0x69 0x65 0x6e 0x74 ("xmpp-client")
+Reference: [XEP-0368]
+
+Protocol: XMPP jabber:server namespace
+Identification Sequence:
+ 0x78 0x6d 0x70 0x70 0x2d 0x73 0x65 0x72 0x76 0x65 0x72 ("xmpp-server")
+Reference: [XEP-0368]
+
The ALPN registry is currently located here.
+ +Issues with direct TLS ports mentioned in &rfc2595; Section 7 do not apply here for these reasons:
+There are no XMPP Registrar Considerations.