Re: QUIC(ker)

On April 5, 2026 3:50:36 AM EDT, Dave Cridland <[email protected]> wrote:
>On Sun, 5 Apr 2026 at 04:49, Travis Burtrum <[email protected]> wrote:
>
>>
>>
>> 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)
>>
>>
>So they go through SASL etc and form a complete XMLStream on each
>connection, under your model? For client sessions, this would mean multiple
>resources? This seems very wasteful.

Sure, if you want, plenty of usecases for that. And if you want a new MUX-like protocol that enables "hey I'm gonna open a new stream that  authenticates this other way" you can. But I see no reason to tie an entire transport to 1 identity or anything like that at the base level.
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]