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

Hi Jacob,

On 2026-07-11 18:00, Jacob Appelbaum wrote:
 >
 > The Kyber hash was not merely nostalgia for Dual_EC_DRBG. It was a
 > cheap defense-in-depth step against exposing raw system RNG output to
 > the recipient. Prof. Dr. Peter Schwabe made that point explicitly during
 > the NIST discussion [0]. FIPS 203 removed that step and instead relies
 > on a requirement for approved randomness generation [1]. That dependency
 > is exactly what the TLS draft should surface.

I agree, that discussion could be generalized and carried over to the 
TLS security considerations. In the case of ML-KEM specifically, you get 
it implicitly for TLS as long as the implementation of ML-KEM is fully 
FIPS 203 conformant. This is what the relevant paragraph on page 16 of 
FIPS 203 says:

"Randomness generation. Two algorithms in this standard require the 
generation of randomness as an internal step: ML-KEM.KeyGen and 
ML-KEM.Encaps. In pseudocode, this randomness generation is denoted by a 
statement of the form 𝑚 ←− 𝔹32. A fresh string of random bytes must be 
generated for every such invocation. These random bytes shall be 
generated using an approved RBG, as prescribed in SP 800-90A, SP 
800-90B, and SP 800-90C [18, 19, 20]. Moreover, this RBG shall have a 
security strength of at least 128 bits for ML-KEM-512, at least 192 bits 
for ML-KEM-768, and at least 256 bits for ML-KEM-1024."

On 2026-07-11 18:00, Jacob Appelbaum wrote:
> Hi Henrick,
> 
> On 7/11/26 13:53, Henrick Hellström wrote:
>> Hi Jacob,
>>
>> On 2026-07-09 18:11, Jacob Appelbaum wrote:
>>  > Obviously no one should use Dual_EC_DRBG. The problem is that users
>>  > often do not know when their randomness source is sabotaged. Hashing
>>  > does not solve all bad-RNG problems, but it does destroy the algebraic
>>  > structure used in this known attack class.
>>
>> Yes, I understand this might once have been brought in as a quick-fix 
>> for Dual_EC-DRBG debacle, but at this time it ought to be replaced by 
>> a more permanent fix.
>>
> I agree that a permanent fix is better than an ad hoc fix.
> 
> Where I disagree is the implication that the issue has already been
> permanently fixed in the TLS draft. If the permanent fix is "never hand
> raw primary RBG output to ML-KEM.Encaps() as decapsulator-recoverable
> `m`", then that should be stated clearly in the Security Considerations.
> 
> The Kyber hash was not merely nostalgia for Dual_EC_DRBG. It was a
> cheap defense-in-depth step against exposing raw system RNG output to
> the recipient. Prof. Dr. Peter Schwabe made that point explicitly during
> the NIST discussion [0]. FIPS 203 removed that step and instead relies
> on a requirement for approved randomness generation [1]. That dependency
> is exactly what the TLS draft should surface.
> 
>  > Because who exactly do you mean by "user" in this context, and what
>  > kind of conformance certification is required?
> 
> By "user" I mean the people who rely on TLS deployments: browser users,
> citizens using government systems, operators, administrators, device
> owners, library consumers, and people depending on remote services. They
> are usually not in a position to audit whether a hardware RNG, firmware
> RNG, HSM, cloud module, or library RNG is sabotaged.
> 
> That is why this belongs in protocol security guidance. A lab
> conformance story is not the same thing as user protection.
> 
>  > If you would want the implementation to be FIPS 140 conformant, the
>  > randomness source consumed by ML-KEM would have to be an approved
>  > DRBG, but it can be a secondary DRBG, like I described, and it
>  > should be one of the symmetric, more easily analysed DRBGs.
> 
> That may indeed be a good answer if it is mandatory, isolated, and
> specified carefully.
> 
> A secondary symmetric DRBG seeded from a primary RBG can plausibly
> destroy Dual_EC_DRBG-shaped (x-coordinate) structure, provided that raw
> primary output is not exposed elsewhere and the secondary DRBG is
> properly instantiated, reseeded, separated by use, and implemented. If
> that is the intended FIPS-friendly permanent fix, then the draft should
> say so.
> 
> What the draft should not do is silently inherit the assumption
> "approved RBG" as if that alone answered the historical failure mode.
> Dual_EC_DRBG was once standardized in the same general standards family.
> The lesson should not be "trust the label"; it should be "do not expose
> structured RBG output when cheap separation or whitening avoids it."
> 
>  > On the other hand, if you add a hash between the approved DRBG and
>  > the ML-KEM implementation, it would become an algorithm that clearly
>  > differs from the specifications and requirements of NIST SP 800-90,
>  > so I doubt it would be FIPS 140 certifiable.
> 
> This may be true for a strict FIPS validation boundary. If so, it is not
> a rebuttal; it is the problem stated plainly. Also, this isn't a draft 
> about FIPS per se, though it is clearly very related to IETF finding 
> consensus on FIPS 203.
> 
> If restoring Kyber's `m <- H(m)` step would make an implementation no
> longer FIPS 140 certifiable as ML-KEM, then the TLS draft should say
> what FIPS-constrained implementations are expected to do instead. For
> example: use an approved, separate, symmetric DRBG or approved
> derivation construction for ML-KEM encapsulation randomness, with domain
> separation, so that raw primary RBG output is never used directly as
> `m`.
> 
> For non-FIPS-constrained implementations, Kyber-style hashing or
> context-bound derivation of `m` remains the simple defense-in-depth
> answer. For FIPS-constrained implementations, the answer may be a
> validated secondary DRBG construction. Either way, the security goal is
> the same: do not give the decapsulating peer a clean sample of raw,
> structured RNG output.
> 
> So I think we may be closer than it first appeared. If your position is:
> 
>    "Do not use raw primary RBG output directly as ML-KEM `m`; use a
>    properly separated approved secondary DRBG instead if FIPS validation
>    is required"
> 
> then I would appreciate seeing that written into the draft's Security
> Considerations, along with the reason it matters to implementers.
> 
> Kind regards,
> Jacob
> 
> [0] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/ 
> m/o2XJ2YvfAwAJ
> 
> [1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
> 
> [2] https://csrc.nist.gov/pubs/fips/140-3/final
> 
>>> On 7/9/26 10:39, Henrick Hellstrom wrote:
>>>
>>>> On 2026-07-09 10:10, Tanja Lange wrote:
>>>>
>>>>> The question by Benjamin Kaduk was if there are cases where the
>>> server hellow would not leak the state of the PRNG (adding P for
>>> clarity^*) and Botan implements that protection. There are other
>>> libraries that have seperate PRNGs for public and private values.
>>>
>>> To further support Tanja's point: The sub-topic is not ordinary PRNG
>>> quality. It is avoiding leakage of bytes that can form a covert channel
>>> and carry algebraic structure from kleptographic RNGs such as
>>> Dual_EC_DRBG. That kind of leakage can happen through many protocol
>>> fields, including TLS fields, and it is a specification-level defense-
>>> in-depth gap.
>>>
>>> ML-KEM as finalized in FIPS 203 removed Kyber's hash over `m`, even
>>> though at least one Kyber designer explicitly argued that hashing `m`
>>> avoids sending system RNG output to the recipient [0]. NIST later
>>> announced that the hash would be removed [1]. I have not seen an
>>> analysis from NIST showing that this removal remains safe against their
>>> own historical example: Dual_EC_DRBG, a DRBG NIST described as "provided
>>> by NSA," which NIST later said there were many reasons to reject or
>>> modify, but "instead, we left it in" [2][3].
>>>
>>> Any such analysis would have had to address the central point: hashing
>>> destroys the Dual_EC_DRBG algebraic structure needed for efficient state
>>> recovery.
>>>
>>>> Yes, but just hashing the output from a DRBG is not the approved way
>>> to do it. Instead you are supposed to spawn a secondary DRBG with a seed
>>> generated from a primary DRBG.
>>>
>>> That may be an approved construction for ordinary DRBG engineering, but
>>> it is not obviously a defense against a DRBG whose output is
>>> intentionally structured to leak its state. If the primary DRBG is
>>> Dual_EC_DRBG-shaped, spawning another DRBG from it may simply give the
>>> defender two things to audit. Please point me to the specific approval
>>> text you mean where the "do it" is defending against this class of
>>> Dual_EC_DRBG kleptographic backdoor.
>>>
>>> Dual_EC_DRBG output can look secure by many metrics and still act as a
>>> covert channel [4]. With the relevant trapdoor/secret key(s), an
>>> Adversary who can sample enough output can recover DRBG state and
>>> predict future outputs. The general attack is well established [5][6]
>>> [7]. The RSA/Dual_EC_DRBG reporting and the BULLRUN reporting are the
>>> relevant historical context here [8][9].
>>>
>>> Obviously no one should use Dual_EC_DRBG. The problem is that users
>>> often do not know when their randomness source is sabotaged. Hashing
>>> does not solve all bad-RNG problems, but it does destroy the algebraic
>>> structure used in this known attack class.
>>>
>>>> Just hashing wouldn't do much good, if you are really concerned that
>>> the DRBG output might reveal anything about the internal state.
>>>
>>> For this attack class, it does good.
>>>
>>> Hashing `m` during `ML-KEM.Encaps()`, for example with the ML-KEM public
>>> key and/or transcript context, binds `m` to context before the ML-KEM
>>> ciphertext is sent. In the normal non-ECH TLS 1.3 case, that closes the
>>> Dual_EC_DRBG-shaped oracle against the server's RNG output. With ECH
>>> using ML-KEM or a hybrid KEM, the same concern can arise in both 
>>> directions.
>>>
>>> A few objections have come up repeatedly:
>>>
>>> 0. Ad-hominem attacks
>>>
>>> 1. TLS already has random fields written to the wire, so we should not
>>> worry about ML-KEM
>>>
>>> 2. NIST already issued FIPS 203, so the IETF should not revisit the 
>>> issue
>>>
>>> 3. Updating drafts, RFCs, or implementations would be work
>>>
>>> 4. The issue also affects hybrids, so the hybrid recommendation should
>>> be weakened
>>>
>>> 5. Hashing may not increase entropy
>>>
>>> 6. Hashing DRBG output merely creates a new DRBG, DRBG'
>>>
>>> Briefly:
>>>
>>> 0. The IETF mission is to make the Internet work better for the people
>>> who use and manage it [10], and the IETF considers pervasive monitoring
>>> an attack [11]. Cryptographic sabotage is part of how pervasive
>>> monitoring becomes actionable intelligence. Attacking the person raising
>>> the issue is irrelevant to the technical question.
>>>
>>> 1. It is true that TLS has a broader problem with raw random bytes in
>>> protocol-visible fields. That is a reason to fix the broader issue, not
>>> a reason to preserve the same problem in ML-KEM. Tanja pointed out that
>>> Botan already has a TLS protection strategy. Other libraries use
>>> different ad-hoc strategies, or none. That is exactly why IETF guidance
>>> would help.
>>>
>>> 2. FIPS 203 being final is not the end of the story. NIST can publish
>>> errata, revisions, or clarifications. NIST withdrew Dual_EC_DRBG after
>>> public reporting on BULLRUN and related cryptographic sabotage. A NIST
>>> participant who described himself as a main author of FIPS 203 is on
>>> this list, and I have asked for clarification on both the hashing
>>> decision and the IPR implications.
>>>
>>> 3. Yes, updates take work. That is not a security argument. If the
>>> Security Considerations of the draft omit an important assumption and a
>>> cheap mitigation, that should be fixed. This is a constructive
>>> suggestion and an easy win to build consensus.
>>>
>>> 4. The issue also applies to hybrid X25519MLKEM* constructions. The
>>> answer is not to weaken hybrids; it is to hash `m` in the ML-KEM
>>> component. Failure to hash `m` can contribute to compromising later
>>> values, including later X25519 keypairs, if the same long-running RNG
>>> state is used and no strong reseed or unknown additional input 
>>> intervenes.
>>>
>>> 5. Hashing Dual_EC_DRBG output does not magically add entropy, and may
>>> reduce it in some constructions. That is not the point. The point is
>>> destroying hidden algebraic structure. We should not shift the
>>> discussion from structure recovery to entropy accounting and then
>>> conclude that no mitigation is useful.
>>>
>>> 6. Yes, hashing DRBG output can be described as constructing DRBG'. That
>>> is fine. DRBG' should still be treated as suspect, but it no longer
>>> preserves the Dual_EC_DRBG x-coordinate structure needed by the
>>> published attacks. Unkeyed hashing appears sufficient to block the known
>>> Dual_EC_DRBG recovery attacks; a keyed hash may be useful for stronger
>>> designs, but it is not needed to make this point.
>>>
>>> My conclusion is simple: when history and user-centered harm reduction
>>> are the concern, the arguments favor hashing. We know this class of
>>> kleptographic attack is real. We know standards influence is part of the
>>> game. We should not leak raw pre-whitened system entropy to the network,
>>> and we should not hand raw RNG-derived `m` to a potentially adversarial
>>> decapsulator.
>>>
>>> To restate the completely obvious: this isn't an accusation of a
>>> backdoor in ML-KEM. It is a statement of fact that a defense-in-depth
>>> protection was knowingly removed by NIST. NIST did so over the objection
>>> of several people participating in the NIST PQC process, and without
>>> analysis that accounts for the extremely serious failures of NIST in the
>>> very recent past with regard to Dual_EC_DRBG. The change by NIST serves
>>> as an example where surprise: no one is responsible for the user's
>>> security even though the difference in exploitability for the
>>> Dual_EC_DRBG scenario is roughly a single hash function call.
>>>
>>> The IETF should give implementers clear guidance and it should be in the
>>> draft's Security Consideration at the very least. Hash `m`. Relatedly,
>>> do not write raw RNG output into protocol-visible fields when cheap
>>> whitening destroys known hidden structure.
>>>
>>> Kind regards,
>>> Jacob Appelbaum
>>>
>>> P.S.
>>>
>>> Consider also the scale of the budgets for only a single agency [12]. It
>>> may also be worth your time looking at the cryptographic libraries
>>> worked on by former NSA people once they were officially out of
>>> government and firmly on the defending side of the fence. It is also
>>> informative for spotting the folks who have retained their first job
>>> while taking on another, another thing we learned about PROJECT BULLRUN.
>>> Remember: there is no need for accusations of a conspiracy as the
>>> business plan as the documented [12] attack budget appears to exceed the
>>> IETF's operating budget by a very large margin. The larger issue isn't
>>> even really about the NSA as the NSA's track record serves as a fairly
>>> clear example of what to look for from many other large-scale 
>>> adversaries.
>>>
>>> [0] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ 
>>> WFRDl8DqYQ4/ m/o2XJ2YvfAwAJ
>>>
>>> [1] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ 
>>> WFRDl8DqYQ4/ m/MRa5O0CvAAAJ
>>>
>>> [2] https://rwc.iacr.org/2015/Slides/RWC-2015-Kelsey-final.pdf
>>>
>>> [3] https://csrc.nist.gov/csrc/media/projects/crypto-standards- 
>>> development-process/documents/dualec_in_x982_and_sp800-90.pdf
>>>
>>> [4] https://csrc.nist.gov/glossary/term/covert_channel
>>>
>>> [5] https://rump2007.cr.yp.to/15-shumow.pdf
>>>
>>> [6] https://eprint.iacr.org/2015/767
>>>
>>> [7] https://www.usenix.org/system/files/conference/usenixsecurity14/ 
>>> sec14-paper-checkoway.pdf
>>>
>>> [8] https://www.reuters.com/article/world/exclusive-secret-contract- 
>>> tied-nsa-and-security-industry-pioneer-idUSBRE9BJ1C5/
>>>
>>> [9] https://www.theguardian.com/world/2013/sep/05/nsa-gchq- 
>>> encryption- codes-security
>>>
>>> [10] https://datatracker.ietf.org/doc/html/rfc3935
>>>
>>> [11] https://datatracker.ietf.org/doc/html/rfc7258
>>>
>>> [12] https://archive.nytimes.com/www.nytimes.com/ 
>>> interactive/2013/09/05/ us/documents-reveal-nsa-campaign-against- 
>>> encryption.html
>>
>

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