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

[Marco Oliverio <[e-mail]>]

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