[TLS] Re: Deployability of DTLS 1.3, HRR, and MLKEM512X25519

[Martin Thomson <[e-mail]>]

Hi Marco,

Yeah, I remember thinking that this was pretty unfortunate.  It's a hard problem, because making DTLS work like QUIC here, while desirable, would require a very big change to how ClientHello is shaped.  I have a rough idea of what it might look like, which would be hugely disruptive, but it might be workable.

Consider sending a one packet CH that contains a new extension.  Call this new extension "fragmented extensions".  In handshake that would exceed one packet, you take any stuff that might cause the packet to get big and which isn't necessary for getting an HRR (which could be most extensions, except the cookie, though SNI is probably necessary on the basis of it being used for routing; working out what needs to always be present is tricky).  Then you put parts of the other extensions in the new extension.  The server would then be assured that it gets everything it needs.  It can generate an HRR and also be assured of getting the cookie after the routeability check as well, because this would be used both before and after HRR.

What enters the transcript is the reconstructed HRR, which would include a zero-length stub where the fragmented extension extension is (which preserves the entire semantics of all the extensions, their order and that they were fragmented), followed by all the extensions that were fragmented.  This can even work with PSK in that case.  The one trick there is that after HRR you would drop everything that was after the fragmented extension when computing the hash that goes into the transcript.

This could cleanly fall back to TLS 1.2, which is unlikely to need a multi-packet ClientHello anyway.

I'm curious as to whether something this disruptive would be workable.  It's certainly not easy to implement.

On Mon, Aug 31, 2026, at 13:52, Marco Oliverio wrote:
> Hi,
>
> Clients sending ClientHello messages larger than MTUs (because of PQ 
> keys) can't be serviced statelessly while the client's 
> return-routability is not asserted. 
> The problem was discussed here: 
> https://mailarchive.ietf.org/arch/browse/tls/?q=draft-ietf-tls-rfc9147bis 
>
> wolfSSL defaults to sidestepping the problem by requiring a 
> non-fragmented first ClientHello, this breaks interoperability.
>
> wolfSSL can disable these requirements (as NSS does), trading off DoS 
> protection for strict RFC adherence.
>
> wolfSSL is actively working on improving interoperability support and testing.
>
> Regards,
> Marco
>
> On Mon, Aug 31, 2026 at 12:58 PM Martin Thomson <[e-mail]> wrote:
>> Have you tested NSS?  We've had that deployed for a pretty long time now in Firefox and - aside from some early problems - we haven't seen problems, including with HRR.
>> 
>> We have no plans to implement ML-KEM-512, in either form.  Our early estimates showed that it doesn't always fit in an MTU when other TLS ClientHello overheads are considered, so I'm not sure if it really saves much.  And if HRR is as broken as you suggest, that leaves a serious risk of ecosystem fragmentation.
>> 
>> On Mon, Aug 31, 2026, at 12:38, John Mattsson wrote:
>> > Hi,
>> >
>> > We frequently conduct interoperability testing using our internal test 
>> > suite, CipherSnake. We recently expanded the test suite to cover DTLS 
>> > 1.3 and HelloRetryRequest (HRR).
>> >
>> > * DTLS 1.3 appears essentially undeployable in its current state. As 
>> > far as I know, BoringSSL and wolfSSL are currently the only libraries 
>> > claiming support for RFC 9147, and in our tests they do not 
>> > interoperate. I assume we will have to wait for RFC 9147bis and 
>> > subsequent implementation work before DTLS 1.3 can realistically be 
>> > deployed.
>> >
>> > * Relying on HRR for middlebox traversal of large ClientHellos is 
>> > questionable. When discussing the need for ML-KEM-512, several people 
>> > argued that it was unnecessary because HRR could be used instead. 
>> > However, after testing HRR interoperability across 11 TLS libraries, 
>> > our conclusion is that several libraries do not interoperate, making 
>> > reliance on HRR problematic. It is therefore good to see that 
>> > MLKEM512X25519 has recently been registered, although future library 
>> > support remains uncertain. In contrast, support for standalone 
>> > ML-KEM-512 appears to be good.
>> >
>> > Cheers,
>> > John Preuß Mattsson
>> > _______________________________________________
>> > TLS mailing list -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>> 
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]