First draft, based on suggestions from Eric Rescorla.
End-to-end encryption of traffic sent over the Extensible Messaging and Presence Protocol (XMPP) is a desirable goal. The Jabber/XMPP developer community has experimented with several such technologies, including OpenPGP (Current Jabber OpenPGP Usage (XEP-0027)
TLS is the most widely implemented protocol for securing network traffic. In addition to applications in the email infrastructure, the World Wide Web (HTTP Over TLS; see RFC 2818
The basic idea behind XTLS is that two XMPP entities negotiate an encrypted "tunnel" between themselves over XMPP. The tunnel is negotiated using standard TLS handshake data, contained in XMPP <iq/> stanzas and encapsulated as Base64-encoded payloads of a <data/> element qualified by a dedicated namespace. The entities can then exchange TLS-encrypted XMPP stanzas over that tunnel.
XTLS is not limited to client-to-client encryption, since it can be used between two XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream, such as a Multi-User Chat (XEP-0045)
It is intended that this specification will address the requirements specified in Requirements for Encrypted Sessions (XEP-0210)
In XTLS, the initiator functions as a TLS client and the responder functions as a TLS server.
To start the use of XTLS, the initiator sends an IQ-set containing a <start/> element qualified by the 'urn:xmpp:tmp:xtls' namespace (see Protocol Namespaces regarding issuance of one or more permanent namespaces).
(Note: This is the functional equivalent of the <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> command for direct XML streams as specified in RFC 3920.)
If the responder supports XTLS and agrees to start the use of XTLS, it returns an IQ-result containing a <proceed/> element qualified by the 'urn:xmpp:tmp:xtls' namespace (see Protocol Namespaces regarding issuance of one or more permanent namespaces).
(Note: This is the functional equivalent of the <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> command for direct XML streams as specified in RFC 3920.)
If the responder does not support XTLS, in accordance with core XMPP semantics it MUST return a <service-unavailable/> error.
If the responder supports XTLS but does not wish to proceed with the use of XTLS, it MUST return a <not-acceptable/> error.
It is possible that both parties will attempt to start the use of XTLS at the same time
In this example, juliet@capulet.com/balcony is sorted before romeo@montague.net/orchard and therefore her XTLS start stanza has a higher priority. Therefore she would return a conflict error to Romeo if they both send an XTLS start stanza at the same time.
C2C Authentication Using TLS (XEP-0250)
If the responder supports XTLS, agrees to start the use of XTLS, and can verify the X.509 fingerprint, it returns an IQ-result containing a <proceed/> element with its offer.
If the initiator detects that a TLS handshake will fail based on the received offers (e.g. the peer only supports X.509 certificates and the client is unable to verify the certificate), the initiator MUST close the tunnel immediately (see Closing the XTLS Tunnel).
Before sending encrypted data, the parties MUST perform a TLS handshake to establish the the XTLS tunnel. The TLS library sends the handshake and all encrypted data in-band as Base64-encoded payload of a <data> element qualified by the 'urn:xmpp:tmp:xtls' namespace (see Protocol Namespaces regarding issuance of one or more permanent namespaces). (This is similar to how data is sent in-band using In-Band Bytestreams (XEP-0047)
Note: It is possible that XTLS stanzas will not respect TLS message boundaries; therefore the number of IQ stanzas depends on the TLS implementation.
The responder then acknowledges the stanza and, if the stream contains the complete ClientHello message, it continues with the TLS handshake. Otherwise it will wait for more messages from the initiator.
After the TLS handshake has been completed, the parties exchange encrypted data over the tunnel. Because the routing information is already present in the IQ stanzas used by XTLS, it is OPTIONAL for the stanzas encapsulated in the XTLS stream to include routing information (i.e., the 'from' and 'to' attributes). In that case, the entity receiving the data MUST supply the 'from' and 'to' addresses of the IQ stanza that contains the encrypted data.
The sender's client would strip off the routing information.
This message is then encrypted and sent in one or more stanzas over the XTLS tunnel.
Either party can close the XTLS tunnel; this is done by sending an IQ-set containing an empty <close/> element qualified by the 'urn:xmpp:tmp:xtls' namespace (see Protocol Namespaces regarding issuance of one or more permanent namespaces). However, if the entities have a mutual presence subscription then it is RECOMMENDED for the entities to maintain the tunnel until one entity becomes unavailable. Keeping the XTLS tunnel open does not require significant resources and prevents the need for a new TLS handshake.
The other party then acknowledges that the tunnel is closed by sending an IQ-result containing an empty <closed/> element qualified by the 'urn:xmpp:tmp:xtls' namespace (see Protocol Namespaces regarding issuance of one or more permanent namespaces).
If the tunnel is unknown to the receiving party, it MUST return an <item-not-found/> error.
If an error is detected, the tunnel MUST be considered closed and invalid.
As mentioned, XTLS is intended to address the requirements specified in XEP-0210 (or a reasonable subset thereof). This section compares XTLS against the requirements and points out gaps that might need to be filled with changes to XTLS or to TLS itself.
If an entity wishes to request the use of XTLS, it SHOULD first determine whether the intended responder supports the protocol. This can be done directly via Service Discovery (XEP-0030)
If an entity supports XTLS, it MUST report that by including a service discovery feature of "urn:xmpp:tmp:xtls" in response to disco#info requests (see Protocol Namespaces regarding issuance of one or more permanent namespaces).
Both service discovery and entity capabilities information could be corrupted or intercepted; for details, see the Denial of Service section of this document.
This entire document addresses security. Particular security-related issues are discussed in the following sections.
An implementation MUST at a minimum support the TLS_RSA_WITH_3DES_EDE_CBC_SHA and TLS_DH_RSA_WITH_AES_256_CBC_SHA ciphers. An implementation MAY support other ciphers as well.
As noted, XTLS can be used between XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream), or between remote XMPP services. Therefore, a party to an XTLS tunnel will present either a client certificate or a server certificate as appropriate. Such certificates MUST be generated and validated in accordance with the certificate guidelines guidelines provided in rfc3920bis
A future version of this specification might provide additional guidelines regarding certificate validation in the context of client-to-client encryption.
The XTLS start stanzas and proceed stanzas are not encrypted or signed; the same is true of service discovery exchanges and entity capabilities data. Therefore it is possible for an attacker to intercept these stanzas and modify them (e.g., by spuriously returning a <service-unavailable/> error), thus convincing the initiator that the responder does not support XTLS and therefore denying the parties an opportunity to use XTLS.
A future version of this specification might address this problem.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)
Until this proposal is accepted for publication by the XSF, its associated namespace shall be "urn:xmpp:tmp:xtls". Upon publication as a XEP, the XMPP Registrar
]]>
The authors wish to thank Eric Rescorla for initial suggestions regarding the use of TLS for application-layer encryption in XMPP. Thanks also to Joe Hildebrand and Remko Tronçon for their comments and suggestions.