I do not support publication of draft-ietf-tls-mlkem-08 in its current form.
My objection rests on uncontested text in FIPS 203 itself. Appendix C.1 (third
bullet) documents that the round-3 Kyber step m <- H(m) was removed from
ML-KEM.Encaps, and states the rationale plainly:
"The purpose of this step was to safeguard against the use of flawed randomness
generation processes. As this standard requires the use of NIST-approved randomness
generation, this step is unnecessary and is not performed in ML-KEM."
That is a conditional judgment: the safeguard was deemed unnecessary because
FIPS 203 Section 3.3 mandates an approved RBG (SP 800-90A/B/C) at the parameter
set's security strength. An IETF RFC imposes no such mandate, and the majority
of TLS implementations in the field are not FIPS-validated modules. Standalone
ML-KEM in TLS therefore inherits the removal of a designed-in safeguard while
lacking the precondition NIST cited to justify removing it. One need not take
any position on specific attack mechanisms to observe that this gap exists and
that the draft neither closes it nor discloses it.
The formal analyses cited in support of the draft do not reach this question:
symbolic-model verification of KEM substitution in TLS 1.3 treats randomness as
ideal by construction. Those results validate the protocol composition, which I
do not dispute; they are silent on security under degraded or flawed randomness
generation, which is precisely the condition the removed safeguard addressed.
I acknowledge that the draft requests Recommended=N, and that codepoints for
constrained deployments differ from a recommendation. This mitigates but does
not resolve the concern: registry entries published in an IETF-stream RFC carry
weight with implementers and procurement processes regardless of the
Recommended column.
More broadly, retaining the established hybrid default
(draft-ietf-tls-ecdhe-mlkem) costs roughly 32 bytes and negligible computation
against kilobyte-scale ML-KEM key material. Accepting that small, known cost to
avoid a large, plausible tail loss is sound engineering even without endorsing
pessimistic estimates of that loss's probability. Migration from hybrid to
standalone ML-KEM gives up that asymmetry for essentially nothing.
Should the WG proceed despite these objections, the Security Considerations
should at minimum (a) state explicitly that ML-KEM's security argument assumes
randomness of approved-RBG quality, (b) cite FIPS 203 Appendix C.1 so
implementers understand the m-hash removal and its stated precondition, and (c)
reaffirm hybrid key agreement as the recommended deployment.
David Gessel
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
