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

[Frederik Wedel-Heinen <[e-mail]>]

I don’t know if it is of interest but the DTLS 1.3 implementation in OpenSSL was recently merged to master and will be available in the 4.1 release expected in October.

@Ryan Hooper, I remember I had some issues when integration testing with WolfSSL around fragmented client hellos. But I forgot the details, maybe you can chime in on this thread?

Regards
Frederik

Den 1. sep. 2026 kl. 09.01 skrev John Mattsson <john.mattsson=[e-mail]>:


Hi Martin,

We did not test the DTLS 1.3 implementation in NSS. I will check with my colleagues whether they can include it in our testing. The DTLS 1.3 and TLS 1.3 HRR tests were independent of each other. We tested NSS’s TLS 1.3 implementation and did not find any bugs.

Some of our findings were:

* TLS 1.3 HRR: wolfSSL and mbedTLS do not echo the HRR cookie as mandated by RFC 9846.

* DTLS 1.3: BoringSSL and wolfSSL do not interoperate in their default configurations, regardless of which library acts as the client or server. Testing the default configuration is important, as this is what users are most likely to deploy. Based on your comments, I assume BoringSSL and NSS interoperate.

* DTLS 1.3 HRR: BoringSSL does not handle an empty ClientHello key share, which should trigger an HRR.

* DTLS 1.3: wolfSSL drops fragmented ClientHello messages.

Cheers,
John Preuß Mattsson

From: Martin Thomson <[e-mail]>
Date: Monday, 31 August 2026 at 12:58
To: [e-mail] <[e-mail]>
Subject: [TLS] Re: Deployability of DTLS 1.3, HRR, and MLKEM512X25519

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]
_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]