Answering the several responses together, and an attempt to add a bit to Ben
Kaduk's procedural point: whether the concern is valid, and what dealing with
it everywhere it applies would look like.
My objection asserts no backdoor and no mathematical flaw in ML-KEM, and
requires no opinion on either, nor would my opinion on the mechanics deserve
any weight. It is narrower: FIPS 203 Appendix C.1 documents the removal of a
designed-in safeguard against flawed randomness, with a stated precondition
(mandated NIST-approved randomness generation) that IETF-stream documents do
not impose. That is merely administrative, not an algorithm critique, and the
request is merely for disclosure plus a default-selection judgment about
failure containment.
On "the same issue" (Paul) and "by the same logic" (Scott): the ML-KEM component is identical in both documents; the consequence of its failure is not. Security against present adversaries and security against a future CRQC are separate quantities. If ML-KEM holds, hybrid and standalone have (likely) identical post-quantum strengths. If some flaw is found in ML-KEM, hybrid's retains today's TLS strength against whatever advantage quantum gives attackers, but there is a non-zero possibility of an algorithmic or implementation failure that compromises the inarguably less proven ML-KEM. My objection is, and was, about the worst-case not expected, so the argument applies to both documents and is discharged by construction in one of them. Scott's framing in fact supports the disclosure request: if hybrid's post-quantum guarantee rests entirely on ML-KEM, the documented randomness precondition deserves notice wherever ML-KEM appears. Which is also my answer to Paul's direct
question: yes, the same Security Considerations text belongs in draft-ietf-tls-ecdhe-mlkem where it is provides information value at trivial cost.
The floor argument requires no pessimism about ML-KEM. Sophie Schmieg, who has rebutted the backdoor claims in detail and whose stated trust in lattice cryptography is "pretty much equal to my trust in elliptic curves," nonetheless assesses that further lattice-reduction improvements are "likely to occur" and may chip at effective security levels. She describes structural algebraic attacks against MLWE as "far scarier," and concludes of TLS key exchange that "hybrids are the best way to go" [1][2]. None of ML-KEM's plausible failure classes; incremental cryptanalytic erosion, a structural algebraic advance, or an implementation fault of the KyberSlash type surviving into wide deployment; shares a mechanism with ECDH. Simultaneous failure requires two independent events; the hybrid premium is roughly 32 bytes per handshake. Accepting that trade needs no estimate of the probability of those events, only the observation that the cost is small, known, and bounded, and the avoided
loss is none of those things.
To David Benjamin's point that entropy guidance belongs uniformly at the TLS
level: agreed, for the uniform requirement -- generate good randomness -- which
RFC 8446 Appendix C.1 covers. It cannot, however, carry an algorithm-specific
design fact that postdates it: that this algorithm's internal safeguard against
flawed randomness was removed in standardization, expressly conditioned on a
randomness mandate absent here. A reader of RFC 8446 cannot learn that from RFC
8446. One sentence and a citation in the algorithm document complements the
generic guidance; it does not duplicate it.
None of this asks the WG to re-litigate ML-KEM. It asks that a documented,
conditional design decision be disclosed where its condition does not hold, and
that the recommended default remain the construction whose worst case is the
status quo rather than one whose worst case is a regression below it.
[1] https://keymaterial.net/2025/11/27/ml-kem-mythbusting/
[2] https://keymaterial.net/2023/11/18/kyber512s-security-level/
David Gessel
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
