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

On Mon, Aug 10, 2026 at 11:34:56AM +0200, Marco Oliverio wrote:
> Big PQC key shares are problematic for servers that handle connections
> statelessly until the return-routability cookie check completes.
> Such a server cannot defragment the initial ClientHello statelessly.
> A client MAY send an empty key share in the first ClientHello, but even the
> post-HRR ClientHello can exceed the datagram limit, and a stateless server
> cannot locate the cookie in a fragmented CH2 either.
> 
> I'd rather not see that cost become non-negotiable for everyone, so before
> proposing text: have the authors already considered this case, and is there
> a better answer than making all clients pay for the servers that need
> statelessness?

What I think I would do is to have global LRU reassembly cache (bypassed
by atomic reassembly) keyed by the five-tuple and if message_seq is
zero or not. When any entry completes (or if atomic message is receved),
it is handed to handshake code (and deleted from cache if possible). The
fragments are never committed, so never ACKed (the SH/HRR will serve as
implicit ACK).

The reason for considering if message_seq is 0 or not in cache key is
so that delayed CH1 fragments received during CH2 are not confused with
genuine CH2 fragments (which would mess up the handshake). CH1 has
message_seq 0, CH2 has message_seq 1.

A drawback is that under conditions involving heavy connect attempts
(which can come from spoofed sources), it could be difficult for a
legimate client to get (stronger than level 1) PQC connection
established.




-Ilari

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]