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

[Martin Thomson <[e-mail]>]

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]