XEP-xxxx: XMPP over QUIC

1. Introduction¶

XMPP Core [1] specifies the use of STARTTLS to connect to an XMPP server. SRV records for XMPP over TLS (XEP-0368) [2] extends that to skip STARTTLS by doing Direct TLS. This XEP defines how to negotiate a XMPP connection over QUIC (RFC 9000 [3]), which provides identical security and authentication to TCP+TLS, along with a number of other desirable properties, such as connection migration across IP changes, and multiple independent bidirectional streams in one session, among others.

2. Requirements¶

QUIC session negotiation is virtually identical to TLS. This document specifies that the following additional rules apply:

1. While other forms of discovery like Discovering Alternative XMPP Connection Methods (XEP-0156) [4] can discover QUIC connections, we also define UDP port 443 as the default port to attempt a XMPP-over-QUIC connection on if those are not available, yes this is the reserved port for HTTPS, no we don't care because SNI and ALPN are required so there will be no mishaps.
2. TLS certificates MUST be validated the same way as for STARTTLS. (i.e., as specified in XMPP Core [1]).
3. STARTTLS MUST NOT be used over QUIC connections.
4. Client or server MUST set SNI TLS extension to the JID's domain part, and MUST use TLS Encrypted Client Hello [5] if available.
5. Client or server MUST set the ALPN (RFC 7301 [6]) TLS extension, and MUST use TLS Encrypted Client Hello [5] if available.
6. The ALPN protocol MUST be 'xmpp-client' when negotiating an c2s connection.
7. The ALPN protocol MUST be 'xmpp-server' when negotiating an s2s connection.
8. The client or server MUST use QUIC Connection Migration which allows for a single QUIC session and therefore multiple XMPP connections to migrate between IPs without reconnecting. Use of Stream Management (XEP-0198) [7] is therefore optional but encouraged if reconnection might occur over another transport like TLS or WebSocket.
9. QUIC supports uni-directional and bi-directional streams, but XMPP MUST only use bi-directional streams. Multiple bi-directional MAY be opened in one session and MUST be treated as a seperate connections with the same security and authentication as negotiated in the initial TLS handshake. This means clients can log into multiple accounts, or the same account multiple times over one QUIC session, or servers can open multiple s2s connections over one QUIC session where one of the servers can prove control over multiple domains, for example if the certificate covered multiple domain names.

3. Use Cases¶

Perhaps the most compelling benefit of QUIC over TCP+TLS is connection migration especially for mobile devices which swap between mobile and WiFi often. Multiple connections per QUIC session is also helpful for clients with multiple accounts or servers with multiple streams to each other. The handshake and especially 0-rtt mode will be faster than STARTTLS, and in theory, QUIC in general should be faster than TLS, though perhaps not enough to matter for XMPP.

4. Security Considerations¶

QUIC provides AT LEAST the same level of security as STARTTLS and Direct TLS, and far more privacy with TLS Encrypted Client Hello [5] (which can and should be used with Direct TLS, but this isn't a MUST). QUIC provides more security than STARTTLS if RFC 7590 [8] is not followed, as it isn't subject to STARTTLS stripping. All security setup and certificate validation code SHOULD be shared between the QUIC, STARTTLS and Direct TLS logic as well.

5. IANA Considerations¶

ALPN (RFC 7301 [6]) requires registration of new Protocol IDs. This document re-uses the two Protocol IDs specified in SRV records for XMPP over TLS (XEP-0368) [2], but the ALPN registry (currently located here) should be updated to additionally point to this document.

IANA requires registration of port numbers too (currently located here) but UDP 443 is already assigned to HTTPS, which also requires ALPN, so I think no registration is required.

6. XMPP Registrar Considerations¶

This document requires no interaction with the XMPP Registrar [9].

Appendices

Appendix A: Document Information¶

Series

XEP

Number

xxxx

Publisher

XMPP Standards Foundation

Status

ProtoXEP

Type

Standards Track

Version

0.0.1

Last Updated

2022-06-13

Approving Body

XMPP Council

Dependencies

XMPP Core, XEP-0156, XEP-0368

Supersedes

None

Superseded By

None

Short Name

NOT_YET_ASSIGNED

This document in other formats: XML  PDF

Appendix B: Author Information¶

Travis Burtrum

Email

travis@burtrum.org

JabberID

travis@burtrum.org

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.0.1 (2022-06-13)¶

   First draft.

   tjb

Appendix I: Bib(La)TeX Entry

@report{burtrum2022xepxxxx,
  title = {XMPP over QUIC},
  author = {Burtrum, Travis},
  type = {XEP},
  number = {xxxx},
  version = {0.0.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2022-06-13/2022-06-13},
}

END