[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]