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

The last point is also wrong, for adversaries with access to a quantum
computer. In that case, you very much leak the keygen randomness to the
adversary. But again, this is not much of a problem, given that it's the
output of a freaking random number generator. Which yes, you need to
secure, but also, AES-CTR-DRBG is so ubiquitous that "What if my DRBG is
accidentally not AES-CTR-DRBG" is more or less a moot question.

On Thu, Jul 16, 2026 at 9:44 AM Christian Huitema <[email protected]>
wrote:

>
> On 7/16/2026 3:40 AM, Nadim Kobeissi wrote:
> > Jacob writes:
> >
> >> Fair enough. Here is a start on a minimal list I think the text needs to
> >> cover:
> >>
> >> - cite the third-round Kyber submission;
> >> - cite FIPS 203 Appendix C, where NIST documents removing `m <- H(m)`;
> >> - state the FIPS 203 approved-RBG requirement;
> >> - state that `m` is recovered by the decapsulating peer;
> >> - recommend restoring Kyber's hashing of `m` as defense in depth against
> >>   hidden-structure RBG failures;
> >> - cite Dual_EC_DRBG as the public standardized example.
> >> - quote the relevant part(s) of FIPS 203 C.1
> >>
> >> I can turn that into concrete PR text. Before doing that, I would like
> >> to understand whether the WG is open to text at this level of
> >> specificity, or whether the only text people are willing to consider is
> >> a generic RNG sentence. If the generic sentence is the only thing on
> >> offer, I would request someone else draft it and I am happy to give
> >> feedback.
> > This is incredibly unreasonable to the point of being disruptive. You
> are basically demanding that the IETF undermine the entire point of NIST
> standardization, on top of all your baseless insinuations about personal
> motivations of those who disagree with you and your unreasonable threat
> modeling when thinking about the entire question of `m` in ML-KEM and
> sources of randomness.
>
> I think that the discussion has established a couple of points:
>
> * The MLKEM "decaps" function provides the TLS client with an exact copy
> of the "m" bits chosen by the TLS server.
> * These bits are the direct output of the RNG used by the server in the
> MLKEM "encaps" function.
> * If the RNG does not have backward and forward replay protection, these
> bits can be used to predict past or future outputs of the RNG, and this
> is bad.
> * RNGs that are compromised by some kind of supply chain attack will not
> provide backward and forward protection.
> * The same RNG may or may not be used to derive TLS elements such as the
> Server Random bytes (depending on how implementers understand the
> public/private split discussed in annex C1 of TLS 1.3)
> * Key exchanges based on Diffie-Hellman operating on number fields with
> an associative multiply function do not expose the random bits used for
> generating the key.
>
> The last point is an important difference. An RNG that is "good enough"
> when using classic Diffie-Hellman for key exchange may not be adequate
> for MLKEM. It is definitely worth pointing that out to implementers. The
> reasonable solution is to build a resistant RNG by combining the
> standard RNG with an adequate DRBG [citation-needed].
>
> I would suggest both a simple mention of the problem in the security
> section of both MLKEM based drafts, and a somewhat longer term work on
> an RFC discussing randomness requirement for TLS and maybe other
> security functions.
>
> -- Christian Huitema
>
>
>
>
>
>
> >
> > At what point does this become pure concern trolling? I regret even
> making the effort to catch up on these discussions.
> >
> > Nadim Kobeissi
> > Symbolic Software • https://symbolic.software
> >
> >> On 15 Jul 2026, at 5:25 AM, Jacob Appelbaum <[email protected]>
> wrote:
> >>
> >> Hi Paul,
> >>
> >> On 7/14/26 03:17, Paul Wouters wrote:
> >>> The draft does not define crypto, it normatively references some
> crypto. It cannot both normatively reference it and modify it to make its
> own.
> >> I do not think that follows and while it does not define the code point,
> >> it does define how the cryptography is used in TLS including Security
> >> Considerations. A TLS draft can normatively reference FIPS
> >> 203 and still explain the relevant assumptions and tradeoffs in Security
> >> Considerations.
> >>
> >> FIPS 203 Appendix C itself documents that Kyber originally hashed `m`
> >> and that NIST removed that step because ML-KEM requires approved
> >> randomness generation. The TLS draft should say that plainly.
> >>
> >> Namely, quote the entirety of C.1:
> >> ```
> >> C.1 Differences Between CRYSTALS-Kyber and FIPS 203 Initial Pub-
> >> lic Draft
> >> • In the third-round specification [4], the shared secret key was
> >> treated as a variable-length
> >> value whose length depended on how it would be used in the relevant
> >> application. In this
> >> specification, the length of the shared secret key is fixed to 256 bits.
> >> It can be used directly
> >> in applications as a symmetric key, or symmetric keys can be derived
> >> from it, as specified
> >> in Section 3.3.
> >> • The ML-KEM.Encaps and ML-KEM.Decaps algorithms in this specification
> >> use a different
> >> variant of the Fujisaki-Okamoto transform (see [24, 25]) than the third-
> >> round specifica-
> >> tion [4]. Specifically, ML-KEM.Encaps no longer includes a hash of the
> >> ciphertext in the
> >> derivation of the shared secret, and ML-KEM.Decaps has been adjusted to
> >> match this
> >> change.
> >> • In the third-round specification [4], the initial randomness 𝑚 in the
> >> ML-KEM.Encaps algo-
> >> rithm was first hashed before being used. Specifically, between lines 1
> >> and 2 in Algorithm
> >> 20, there was an additional step that performed the operation 𝑚 ←
> 𝐻(𝑚).
> >> 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.
> >> • This specification includes explicit input checking steps that were
> >> not part of the third-round
> >> specification [4]. For example, ML-KEM.Encaps requires that the byte
> >> array containing the
> >> encapsulation key correctly decodes to an array of integers modulo 𝑞
> >> without any modular
> >> reductions.
> >> ```
> >>
> >> Alternatively highlight this part of C.1 from FIPS 203:
> >> ```
> >> • In the third-round specification [4], the initial randomness 𝑚 in the
> >> ML-KEM.Encaps algorithm was first hashed before being used.
> >> Specifically, between lines 1 and 2 in Algorithm 20, there was an
> >> additional step that performed the operation 𝑚 ← 𝐻(𝑚).
> >> 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.
> >> ```
> >>
> >> Then I would suggest describing the total set of requirements from
> >> FIPS203 or giving advice that `𝑚 ← 𝐻(𝑚)` should be used if the NIST-
> >> approved randomness generation requirement is not met. I would also
> >> probably want to say that this change by NIST is not robust against a
> >> failure of their DRBG, nor is it robust against providing an oracle, the
> >> m-oracle, I suppose which may be queries over TLS and/or used to sample
> >> the DRBG outputs directly.
> >>
> >>> The IETF cannot modify things that are an external normative
> reference. MLKEM is what NIST defined, not what you are trying to build now.
> >> I am not asking the draft to pretend that NIST defined something else. I
> >> am asking the draft to document the consequence of what NIST defined:
> >> without the approved-RBG assumption, the rationale for removing Kyber's
> >> hash over `m` no longer holds.
> >>
> >> If the draft does not restore `m <- H(m)`, then it should at least state
> >> the FIPS 203 approved-RBG requirement and the fact that `m` is recovered
> >> by the decapsulating peer.
> >>
> >> This matters in practice. Many implementations will use `os.urandom`,
> >> `/dev/urandom`, `/dev/random`, `/dev/hwrng`, `getentropy()`,
> >> `getrandom()`, or another platform or library interface. Those may be
> >> excellent choices in a well-designed system, but they are not
> >> automatically the same thing as a NIST-approved RBG satisfying the FIPS
> >> 203 condition used to justify removing the hash.
> >>
> >> One way to make the dependency clear is to think of the real requirement
> >> as something closer to:
> >>
> >> - ML-KEM-512-Hash_DRBG
> >> - ML-KEM-512-HMAC_DRBG
> >> - ML-KEM-512-CTR_DRBG
> >> - ML-KEM-768-Hash_DRBG
> >> - ML-KEM-768-HMAC_DRBG
> >> - ML-KEM-768-CTR_DRBG
> >> - ML-KEM-1024-Hash_DRBG
> >> - ML-KEM-1024-HMAC_DRBG
> >> - ML-KEM-1024-CTR_DRBG
> >>
> >> Listing that is a concrete suggestion for the text but I do not feel
> >> strongly about where it goes in the text.
> >>
> >> These are shorthand examples names and I am not suggesting new algorithm
> >> names. The point is that FIPS 203 relies on an approved RBG of
> >> appropriate strength. If an implementation omits that part, the reason
> >> NIST gave for removing Kyber's hash over `m` no longer applies.
> >>
> >>> This answer circles the answer by not distinguishing between the RNG
> issue and any other issues. You still did not answer the question.
> >> My answer is: not as-is.
> >>
> >> I am open to text that is applied consistently to both ML-KEM drafts.
> >> But a generic sentence about "use a good RNG" does not address the
> >> specific FIPS 203 requirement, nor the protocol consequence that `m` is
> >> recovered by the decapsulating peer.
> >>
> >>> This does answer it better, it seems your answer is "no".
> >> No. My answer is not "no no matter what." My answer is "not as-is"
> >> because your suggestion is not even a full suggestion where I could just
> >> say yes.
> >>
> >>> Which is the same issue as the "m concern".
> >> Related, not identical. The approved-RBG dependency is the assumption
> >> and a requirement. The `m` concern is the protocol consequence when that
> >> assumption is not met, or when it is hidden from implementers.
> >>
> >>> For one, this is not different between pure and hybrid, yet you have
> no issue with the hybrid Security Considerations?
> >> I do have an issue with the hybrid draft on this point. The same
> >> Appendix C tradeoff and the same `m` issue apply there too. Hybrid helps
> >> against some failures, but it does not automatically help if the same
> >> recoverable RBG lineage later feeds the classical ephemeral scalar. The
> >> removal of the hash leads to some fun issues and not only with
> >> Dual_EC_DRBG but also.
> >>
> >>> Second, it seems as people said, TLS already provides a huge amount of
> options and parameters to use as a covert channel.
> >> Agreed. That is why broader covert-channel work is also needed. But that
> >> does not justify leaving this specific ML-KEM issue unexplained in these
> >> drafts. It is a bit annoying to go back and forth between each layer
> >> where a different layer is used as a reason to ignore the issues in the
> >> layer under discussion.
> >>
> >>> What would a TLS implementer need to know when it uses a cryptographic
> library to support a new cipher, whether hybrid or pure?
> >> They need to know at least:
> >>
> >> 1. FIPS 203 requires ML-KEM randomness from a NIST-approved RBG.
> >> 2. `m` is recovered by the decapsulating peer.
> >> 3. Kyber originally hashed `m` to protect against flawed randomness.
> >> 4. Dual_EC_DRBG is the public standardized example of a
> >>    hidden-structure RBG failure.
> >> 5. Hybrid does not automatically help if the same recovered RBG lineage
> >>    later feeds the classical ephemeral scalar.
> >> 6. This change was an intentional choice by NIST and the IETF does not
> >> agree with this change as it cannot mandiate the use of a specific DRBG.
> >>
> >>> First, it seems most of the items you just listed are the same item,
> and basically you want it to say "don't use pure, use hybrid instead",
> >> That is not my position. The `m` issue applies to ML-KEM in both the
> >> standalone and hybrid drafts. My concern is that the drafts do not
> >> clearly state the FIPS 203 randomness requirement, the Appendix C
> >> tradeoff, or the peer-recoverability of `m`.
> >>
> >>> Second, if you want this document to proceed with some newly added
> text, it is up to you to propose such text to the WG.
> >> Fair enough. Here is a start on a minimal list I think the text needs to
> >> cover:
> >>
> >> - cite the third-round Kyber submission;
> >> - cite FIPS 203 Appendix C, where NIST documents removing `m <- H(m)`;
> >> - state the FIPS 203 approved-RBG requirement;
> >> - state that `m` is recovered by the decapsulating peer;
> >> - recommend restoring Kyber's hashing of `m` as defense in depth against
> >>   hidden-structure RBG failures;
> >> - cite Dual_EC_DRBG as the public standardized example.
> >> - quote the relevant part(s) of FIPS 203 C.1
> >>
> >> I can turn that into concrete PR text. Before doing that, I would like
> >> to understand whether the WG is open to text at this level of
> >> specificity, or whether the only text people are willing to consider is
> >> a generic RNG sentence. If the generic sentence is the only thing on
> >> offer, I would request someone else draft it and I am happy to give
> >> feedback.
> >>
> >>> So "pure" is what the IETF is using now for consistency.
> >> Point of clarification: did you mean ML-KEM or ML-KEM-WITH-A-DRBG when
> >> you said pure in that context?
> >>
> >>> The current text is the consensus proposal of two years of talk within
> the TLS WG.
> >> The WGLC for draft-ietf-tls-mlkem-08 has ended, but I have not seen a
> >> declaration of consensus. We also do not yet have agreed text that
> >> addresses the FIPS 203 randomness requirement or Appendix C tradeoff.
> >>
> >>> I am not aware of any technical concerns.
> >> Then let us test that with concrete text. The concern is not merely a
> >> different risk preference. It is that NIST's rationale for removing
> >> Kyber's hash depends on an approved-RBG requirement that the TLS draft
> >> does not clearly carry forward.
> >>
> >>> So to me that makes it clear that in practise, your answer will remain
> "no".
> >> No. If the drafts clearly document the FIPS 203 approved-RBG assumption,
> >> the peer-recoverability of `m`, and the reason Kyber hashed `m`, I am
> >> open to changing my view. If the text is only "use a good RNG", then no,
> >> that is not enough.
> >>
> >>> As I explained above, you providing concrete text additions/
> modifications will help determine consensus of your suggestions
> >> I take that point. I can provide concrete text. My concern is that the
> >> Last Call has already closed, so I am asking how the chairs intend to
> >> handle new text if there is support for it.
> >>
> >>> Rough consensus is achieved when all issues are addressed, but not
> necessarily accommodated.
> >> Agreed. My position is that the issue has not yet been addressed. It has
> >> mostly been reframed as a generic RNG problem, which misses the specific
> >> Appendix C tradeoff and the `m` oracle.
> >>
> >>> The one thing that is clear to me is that what you are asking for is
> basically changing the normative reference.
> >> I reject that framing. Security Considerations routinely explain
> >> assumptions, risks, and implementation guidance around normative
> >> references. That is what I am asking for here.
> >>
> >> The normative reference itself discusses Kyber and ML-KEM together in
> >> Appendix C. Quoting and explaining that text is not changing the
> >> normative reference. It is making the reference intelligible to TLS
> >> implementers.
> >>
> >>> Adding a generic statement about RNG is the only compromise possible.
> >> I do not agree. A meaningful compromise would state the actual FIPS 203
> >> approved-RBG requirement, state that `m` is recovered by the
> >> decapsulating peer, and explain that Kyber originally hashed `m` to
> >> protect against flawed randomness.
> >>
> >>> If that is not good enough for you, your only option is to voice that
> you are against publication -
> >> That is not my only option. I am currently against publication as-is,
> >> but I am also trying to find text that could resolve the issue.
> >>
> >>> and to be consistent, I would expect you to be against publication of
> both the pure and hybrid mlkem drafts, as they are identical in that part,
> using the same normative reference of NIST.
> >> I am against omitting the relevant FIPS 203 Appendix C details in both
> >> drafts. I am against omitting advice to implementers who are not running
> >> a FIPS-validated stack. I am against omitting the fact that `m` is
> >> available to the decapsulating peer. And I am against omitting the
> >> historical example of Dual_EC_DRBG when discussing hidden-structure RBG
> >> failures.
> >>
> >> A suggestion of generic RNG sentence that is not a concrete suggestion
> >> is not enough, no. Text that states the FIPS 203 approved-RBG
> >> requirement, the peer-recoverability of `m`, and the reason Kyber hashed
> >> `m` would be meaningful.
> >>
> >> Kind regards,
> >> Jacob Appelbaum
> >>
> >> _______________________________________________
> >> TLS mailing list -- [email protected]
> >> To unsubscribe send an email to [email protected]
> >
> >
> > _______________________________________________
> > TLS mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[email protected]

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]