[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[John Mattsson <[e-mail]>]

Dan Bernstein wrote:
>ECC+PQ has roughly the same performance properties as non-hybrid PQ

This is not correct. A hybrid such as X25519 + ML-KEM requires substantially more cycles and code size than standalone ML-KEM. The differences are not marginal — they are quantifiable and significant for constrained implementations.
https://blog.cloudflare.com/pq-2025/
https://www.ietf.org/archive/id/draft-spm-lake-pqsuites-01.html

>This document was introduced in pursuit of "CNSA 2.0 compliance"

That claim is contradicted by the inclusion of ML-KEM-512 and ML-KEM-768, neither of which appear in CNSA 2.0. Performance matters directly for practical security. X25519MLKEM768 consumes significantly more code size, CPU cycles, latency, and bandwidth than standalone ML-KEM-512. There are many constrained deployments where these costs matter far more than in the “browse-a-website” scenario that is frequently assumed.

Recently on the TLS mailing list, several participants have argued (correct or not) that they want to reuse “ephemeral” X25519MLKEM768 key shares — in direct violation of FIPS 203 — for performance reasons.

While I strongly agree that X25519MLKEM768 should be the recommended key-exchange method for the Web today, hybrids are far from "strictly better" security-wise. Several standards demonstrate this clearly. For example, the composite-signature mechanisms in LAMPS, as well as ETSI CasKDF, both destroy SUF-CMA (ML-DSA) and IND-CCA2 (ML-KEM) security guarantees that the standalone algorithms provide. That is unlikely to be what users expect when they use a “hybrid.”

Futhermore, the large X25519MLKEM768 key shares causes many legacy middleboxes to reject the connection. In such environments, I think it is preferable to rely on ML-KEM-512 rather than to revert to algorithms that offer no post-quantum protection at all.

(In your “alternative truth” blog post on IETF and corruption you claim that a lot of people in the TLS WG has conflicts of interest. This is ironic, given that you yourself are the author of several algorithms you routinely advocate for...)

Cheers,
John Preuß Mattsson