[TLS] Re: draft-ietf-tls-rfc9147bis: PQC key share CH frag mentation vs stateless server

"Martin Thomson" <[email protected]>
Newsgroups gmane.ietf.tls
Message-ID <[email protected]>
I agree with the sentiment expressed by Ilari and David, but one minor point:

On Tue, Aug 11, 2026, at 09:33, David Benjamin wrote:
> [...] Rather, I think we first try to squeeze what capacity we can out 
> of this design and, if it's not enough, make an extension to follow 
> QUIC in not using HRR for this.

QUIC allows for HRR.  Just not for this sort of state-light offload scenario, just for a miss on the key share guess.  Of course, no one gets THAT wrong outside of testing.

Otherwise, QUIC has all the same problems, but with some differences that might or might not be relevant for your scenario.

A QUIC server will also want to implement a small cache of incomplete Initial fragments in the hope that it can avoid the round trip (which is more work for everyone, including the server).  Of course, you can do both, depending on load and other factors.

The main relevant difference is that QUIC implements Marco's suggestion. With a tweak to handle the fact that there is no "first" fragment, not reliably.  The QUIC Initial that clients send after a Retry always contains tokens.  So every packet contains the confirmation that the server needs about liveness (or whatever caused it not to commit state).

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.