xeps/inbox/xmpp-over-quic.xml

<?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>XMPP over QUIC</title>
  <abstract>This specification defines a procedure to make both c2s and s2s XMPP connections over the QUIC protocol instead of TCP+TLS.</abstract>
  &LEGALNOTICE;
  <number>xxxx</number>
  <status>ProtoXEP</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XEP-0156</spec>
    <spec>XEP-0368</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>2022-06-13</date>
    <initials>tjb</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>
<section1 topic='Introduction' anchor='intro'>
  <p>&xmppcore; specifies the use of STARTTLS to connect to an XMPP server. &xep0368; extends that to skip STARTTLS by doing Direct TLS. This XEP defines how to negotiate a XMPP connection over QUIC (&rfc9000;), 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.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
    <p>QUIC session negotiation is virtually identical to TLS. This document specifies that the following additional rules apply:</p>
    <ol>
      <li>While other forms of discovery like &xep0156; 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.</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 QUIC connections.</li>
      <li>Client or server MUST set SNI TLS extension to the JID's domain part, and MUST use &tls-ech; if available.</li>
      <li>Client or server MUST set the ALPN (&rfc7301;) TLS extension, and MUST use &tls-ech; if available.</li>
      <li>The ALPN protocol MUST be '<strong>xmpp-client</strong>' when negotiating an c2s connection.</li>
      <li>The ALPN protocol MUST be '<strong>xmpp-server</strong>' when negotiating an s2s connection.</li>
      <li>The client or server MUST use <link url='https://datatracker.ietf.org/doc/html/rfc9000#section-9'>QUIC Connection Migration</link> which allows for a single QUIC session and therefore multiple XMPP connections to migrate between IPs without reconnecting. Use of &xep0198; is therefore optional but encouraged if reconnection might occur over another transport like TLS or WebSocket.</li>
      <li>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.</li>
    </ol>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
  <p>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.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
    <p>QUIC provides AT LEAST the same level of security as STARTTLS and Direct TLS, and far more privacy with &tls-ech; (which can and should be used with Direct TLS, but this isn't a MUST). QUIC 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 QUIC, STARTTLS and Direct TLS logic as well.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>ALPN (&rfc7301;) requires registration of new Protocol IDs.  This document re-uses the two Protocol IDs specified in &xep0368;, but the ALPN registry (currently located <link url='https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids'>here</link>) should be updated to additionally point to this document.</p>

<p>IANA requires registration of port numbers too (currently located <link url='https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml'>here</link>) but UDP 443 is already assigned to HTTPS, which also requires ALPN, so I think no registration is required.</p>

</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>This document requires no interaction with the &REGISTRAR;.</p>
</section1>
</xep>