[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

  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]