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

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's just that those two forms of state are very naturally bounded, so you
don't have to do as much work to reason about their DoS potential.

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.

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?)

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.

Is it tight enough that it's a problem? Not sure, that sounds like useful
information to get.

If it is, it may be that dropping HelloVerifyRequest was wrong and we need
to add a partial-ClientHello-compatible reject path to DTLS. This all
ultimately falls out of the DTLS decision to use a transcript-continuing
primitive for this kind of reject. AIUI, QUIC opted *not* to use HRR
cookies as the reject mechanism, and has one outside of TLS that doesn't
need a complete ClientHello before responding.

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.


On Mon, Aug 10, 2026, 09:47 Ilari Liusvaara <[email protected]>
wrote:

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

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