Re: QUIC(ker)

Travis Burtrum <[email protected]> Sat, 04 Apr 2026 23:48:43 -0400
Newsgroups gmane.network.jabber.standards-jig
Message-ID <[email protected]>

On April 4, 2026 5:23:40 PM EDT, Dave Cridland <[email protected]> wrote:
>On Fri, 30 Jan 2026 at 04:19, Travis Burtrum <[email protected]> wrote:
>
>> Nothing in the current XEP  https://xmpp.org/extensions/xep-0467.html
>> forbids multiple streams, in fact it mentions it directly
>>
>> > 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.
>>
>
>I took this to mean ... well, actually I'm not sure what this means. So
>clients can open multiple bi-directional reliable streams, they must be
>treated as seperate connections but with the same security and
>authentication? What does "separate connections" mean if they're
>authenticated the same? Are they the same resource on a C2S? Does the S2S
>mention suggest that each domain pair MUST (MIGHT?) be on a different
>stream, and that we SHOULDN'T mix them?
>
>I think this needs a massive amount more detail.

The same security and authentication of the TLS negotiation, so if you are a client with a connection to a server with a cert you trust that is good for bob.com and tom.com you can open new quic streams for any number of accounts on those domains. But not google.com.  tl;dr only trust your TLS auth when deciding if you can use the connection for this domain. (different XEPs and RFCs might change the way you trust of course)

The server just treats them as entirely seperate connections. so you are free to log in for a session per domain with smacks each if you want. 
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]