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

On Mon, Aug 10, 2026 at 07:33:20PM -0400, David Benjamin wrote:
> With the protocol as it is, I agree with Ilari that's the most reasonable
> option.
> 
> Ultimately all these mechanisms *are* stateful; even "stateless" rejection
> maintains state in the form of:
> - The buffer of unprocessed UDP packets
> - The state on the stack of each thread that is busy processing the reject

It is usually not possible to free stack of running thread, so the
latter usually does not matter (the stack use saturates to maximum).


> Doing a little reassembly is not amazing, but it is doable, e.g. as Ilari
> describes. In particular, just as you had a bound on your UDP receive
> buffer, and a bound on how many threads may be processing stateless
> rejects, you'll want to bound this global reassembly cache to within your
> capacity. Just as with the other bounds, you drop the oldest stuff (by LRU
> presumably) past it.

I would expect whatever thread receives the last fragment of CH1 to
process the stateless reject. Coördination is expensive.


> The question then is whether you can set those bounds such that it's still
> possible to service the requests you need. That's the same question as in
> the "stateless" state, just maybe less obvious. (Can you reply fast enough
> before the UDP receive buffer stops dropping?)

I would expect the problem to be if UDP receive buffer can hold the
fragments long enough for all to arrive, not if you can reply fast
enough.

And in scenario where where reject processing is significant load, I
would drop stuff to shed load and priorize existing clients.

 
> Of course, having to reassemble is definitely more expensive than just
> replying to packets individually. That translates to having a tighter
> bound, which translates to being able to serve less requests before you
> start dropping.

OTOH, since any sane client sends CH as first records (and insane
clients should not expect to be interoperable), it is easy to identify
the packets that need this kind of reassembly.


> I don't think kicking PQ KEMs out of the initial ClientHello is the right
> answer. As you say, that means *everyone* has to pay that extra RTT.
> 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.

I do not think that is the issue here, since processing fragmented
second client hello on stateless reject is just as hard.




-Ilari

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