mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-23 01:32:22 -05:00
ProtoXEP: XMPP over QUIC
This commit is contained in:
parent
f86bc85bc6
commit
c4cf122cf0
70
inbox/xmpp-over-quic.xml
Normal file
70
inbox/xmpp-over-quic.xml
Normal file
@ -0,0 +1,70 @@
|
||||
<?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 ®ISTRAR;.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
2
xep.ent
2
xep.ent
@ -705,6 +705,7 @@ THE SOFTWARE.
|
||||
<!ENTITY rfc8467 "<span class='ref'><link url='http://tools.ietf.org/html/rfc8467'>RFC 8467</link></span> <note>RFC 8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0)) <<link url='http://tools.ietf.org/html/rfc8467'>http://tools.ietf.org/html/rfc8467</link>>.</note>" >
|
||||
<!ENTITY rfc8484 "<span class='ref'><link url='http://tools.ietf.org/html/rfc8484'>RFC 8484</link></span> <note>RFC 8484: DNS Queries over HTTPS (DoH) <<link url='http://tools.ietf.org/html/rfc8484'>http://tools.ietf.org/html/rfc8484</link>>.</note>" >
|
||||
<!ENTITY rfc8285 "<span class='ref'><link url='http://tools.ietf.org/html/rfc8285'>RFC 8285</link></span> <note>RFC 8285: A General Mechanism for RTP Header Extensions <<link url='http://tools.ietf.org/html/rfc8285'>http://tools.ietf.org/html/rfc8285</link>>.</note>" >
|
||||
<!ENTITY rfc9000 "<span class='ref'><link url='http://tools.ietf.org/html/rfc9000'>RFC 9000</link></span> <note>RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport <<link url='http://tools.ietf.org/html/rfc9000'>http://tools.ietf.org/html/rfc9000</link>>.</note>" >
|
||||
|
||||
<!-- Internet-Drafts -->
|
||||
|
||||
@ -745,6 +746,7 @@ THE SOFTWARE.
|
||||
<!ENTITY xmppoverwebsocket "<span class='ref'><link url='https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/'>XMPP Over WebSocket</link></span> <note>An XMPP Sub-protocol for WebSocket <<link url='https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/'>https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/</link>>. Work in progress.</note>" >
|
||||
<!ENTITY bundle "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation/'>Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers</link></span> <note>Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers <<link url='http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation/'>http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation/</link>>. Work in progress.</note>" >
|
||||
<!ENTITY trickle "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-ice-trickle/'>Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol</link></span> <note>Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol <<link url='http://tools.ietf.org/html/draft-ietf-ice-trickle/'>http://tools.ietf.org/html/draft-ietf-ice-trickle/</link>>.</note>" >
|
||||
<!ENTITY tls-ech "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-tls-esni/'>TLS Encrypted Client Hello</link></span> <note>TLS Encrypted Client Hello <<link url='http://tools.ietf.org/html/draft-ietf-tls-esni/'>http://tools.ietf.org/html/draft-ietf-tls-esni/</link>>.</note>" >
|
||||
|
||||
<!-- IANA registries -->
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user