[TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Viktor Dukhovni <[e-mail]>]

On Fri, Oct 10, 2025 at 04:01:56PM -0000, D. J. Bernstein wrote:

> Andrei Popov writes:
> > There are regulatory requirements that require NIST curves, whether
> > one likes them or not.
> 
> Can you please point to the "regulatory requirements" you have in mind,
> and explain why you believe that the requirements prohibit X25519MLKEM*?

IIRC, rumour has it that those who need a FIPS-validated stack, and have
only an older stack with P-256/P-384 validated, but ML-KEM not yet
validated, can get a validated combination via ML-KEM plus ECDSA, but
not ML-KEM with X25519 or X448.

I don't know which software stacks find themselves in this situation,
but what we do see is that these certainly are not showing in deployment
surveys in non-negligible numbers.  So the issue could be more
theoretical than practical.

FWIW, the only hybrid KEM enabled in OpenSSL 3.5+ TLS client and server
by default is "X25519MLKEM768".

-- 
    Viktor.  🇺🇦 Слава Україні!