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

[John Mattsson <[e-mail]>]

Hi Ryan,

Note that having an empty client key share is fully compliant with RFC 9846 and has been recommended as a way to traverse middleboxes that do not like a large initial ClientHello. It is essential to support.

"Clients MAY send an empty client_shares list to request group selection from the server, at the cost of an additional round trip"

"An empty KeyShare.client_shares list is permitted"

Not being able to handle an empty key share is a bug. Good that this was caught early, I assume OpenSSL 4.1 will handle empty KeyShare.client_shares.

---

My collegue Santeri Paavolainen already added NSS DTLS 1.3 to our internal CipherSnake testing. We did not find any bugs in NSS. NSS DTLS 1.3 interoperates with BoringSSL DTLS 1.3 and wolfSSL DTLS 1.3 with the exception that a NSS client and a wolfSSL do not interoperate due to the known wolfSSL bug of not accepting fragmented ClientHellos.

We will work on adding the current pre-release version of OpenSSL 4.1 to our testing tool.

---

Two additional bugs that Santeri found in TLS 1.3 libraries:

LibreSSL: rejects >32 signature_algorithms entries (ClientHello) with decode_error

wolfSSL: missing change_cipher_spec in middlebox compat mode

Cheers,
John Preuß Mattsson

From: Ryan Hooper (ryhooper) <ryhooper=[e-mail]>
Date: Thursday, 3 September 2026 at 23:19
To: Frederik Wedel-Heinen <[e-mail]>; John Mattsson <john.mattsson=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [TLS] Re: Deployability of DTLS 1.3, HRR, and MLKEM512X25519

You don't often get email from ryhooper=[e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hello all,

For OpenSSL I did run some tests between WolfSSL and NSS. For WolfSSL I encountered the empty key share you mention below and a PSK issue, that required a code change on our side. They keep the key_share empty to avoid fragmentation. From what I remember it was for their DTLSv1.3 server solution. We created a support case and they were able to have the client send the key_share in the first client hello, but it isn’t something WolfSSL does out of the box.

Thank you,

Ryan Hooper

From: Frederik Wedel-Heinen <[e-mail]>
Date: Tuesday, September 1, 2026 at 3:15 AM
To: John Mattsson <john.mattsson=[e-mail]>; Ryan Hooper (ryhooper) <[e-mail]>
Cc: Martin Thomson <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [TLS] Re: Deployability of DTLS 1.3, HRR, and MLKEM512X25519

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]