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

Jacob,

I'm reluctantly contributing to this thread, but having quickly
scanned the message below I didn't see any new information amongst
the far-too-many words. Such repetitive text isn't helpful IMO, no
matter what opinion one has of the relevant draft. I suspect that
the level of repetition here is more likely to damage your case
then not. (And a few people here at the IETF hackathon have also
expressed that view to me fwiw.)

Cheers,
S.

On 18/07/2026 15:48, Jacob Appelbaum wrote:
> Hi Nico,
> 
> On 7/17/26 07:35, Nico Williams wrote:
>  > On Fri, Jul 17, 2026 at 12:52:05AM +0200, Jacob Appelbaum wrote:
>>> On 7/16/26 21:57, Nico Williams wrote:
>>>
>>>> The objective answer is that the horse left the barn two decades
>>>> ago when the IETF decided to get out of fighting about national
>>>> cryptographic standards, therefore Deb's 37 years at the NSA are
>>>> irrelevant in this case, and you're fighting the wrong battle if
>>>> you want to change that two-decade-old decision.
>>>
>>> That is not correct and the ISE could easily publish the drafts under 
>>> discussion without consensus as Rob suggested more than a week ago.
>>
>> Has that not been opposed too? / The relevant decision-makers would be 
>> the authors and the Independent Submission Editor. I have not seen a 
>> definitive objection from either, and I understood Eliot to be open to 
>> considering the idea.
>>
>> Would that not be opposed too? It could certainly be opposed. What 
>> kind of opposition do you mean?
> 
> Rob's (it was Rob, right?) suggestion appears to be a viable fallback.
> The Independent Stream does not require IETF rough consensus, although
> it is not an automatic bypass: the authors and ISE would have to pursue
> it, and the IESG would still conduct the RFC 5742 conflict review
> [0][1]. I note that the authors have largely not engaged in discussion.
> 
>> I swear I've seen arguments that users of RFCs don't really understand 
>> these subtle differences in track and editor queues,
>> that they take any RFC as a 'standard'.
> 
> Yes. Many readers treat any RFC number as a standard despite the stream
> boilerplate. That is a real drawback, but it is also why the distinction
> matters for _us_: Independent Stream publication would not assert IETF
> consensus. In practice, I suspect very few outside of the IETF would
> care about the distinction. It would allow us to provide clarity when
> the matter is raised.
> 
> I still prefer resolving the issues in the working group. I am not
> opposed to publication; I am trying to identify text that makes
> publication responsible.
> 
>>>> What you're really litigating is a social death penalty for the NSA 
>>>> -- something we *could* do, but shouldn't.  We really, really 
>>>> shouldn't do that for at least several reasons, such as:
>>>
>>> You may be surprised but I very strongly agree with you. We should
>>> not litigate a social death penalty. I do not advocate for removing 
>>> Deb from the IETF. No one should be harassing her. No one
>>> should be making threats. No one should be giving her a hard time.
>>> No one should be mocking her on social media. No one should be
>>> sending threatening or slanderous or libelous emails.
>>
>> It's not just the invectives against Deb.  It's also the invectives 
>> against the I-D authors and those who have voiced support for the I-
>> D.
> 
> I extend that to everyone: Deb, the authors, supporters, opponents,
> and other participants. We need more technical communication, not
> threats, harassment, ostracism, or censorship.
> 
> I have received several reports of troubling off-list conduct. That
> should be handled through the appropriate conduct process rather than
> mixed into the technical disposition of the drafts. It is unclear to me
> if those reports will by sent by those persons to the IETF out of
> (expressed to me) fear of retaliation.
> 
>> The incessant urging to not publish anything that might be tainted by 
>> the NSA *is* very much akin to a social death penalty for the NSA.
> 
> I do not oppose publication because NSA personnel were involved.
> 
> The immediate concern is a documented NIST design decision: FIPS 203
> removed Kyber's `m <- H(m)` step, whose stated purpose was protection
> against flawed randomness, because FIPS 203 requires approved randomness
> generation [2][3]. The question is whether IETF documents should repeat
> that assumption silently or not, describe and explain the peer-
> recoverable value, and preserve a cheap local safeguard for deployments
> that do not satisfy the full FIPS model.
> 
> It is indisputable that NIST removed the hash over `m`, ignored all
> pushback, ignored official comments on the matter, and unrelated to much
> of the discussion they then also declared that non FIPS-certified
> settings are expected to simply fail catastrophically if the RNG has an
> issue. So you see, removing the hash and qualatatively weakening the
> design of Kyber, they assert is fine. That they accept this outcome and
> state that they are correct was explictly stated by NIST on this very
> list. They additionally also push this without a hybrid construction,
> also over the express concerns of the authors of Kyber. Those two things
> together and my ability to exploit ML-KEM in the Dual_EC_DRBG setting
> correctly raise eyebrows.
> 
> NSA involvement is relevant historical context, but it is not a social
> veto. NIST is not the final technical authority for the IETF, any more
> than BSI, CSE, ETSI, ISO, IEEE, or a corporation would be. Former NIST
> people dropping by to argue that the world should adopt their public
> security posture is unreasonable. They have a traditionally had the
> Suite A and Suite B security postures and we're being offered the B
> option by another name, again. The IETF should have a stronger security
> posture and wihtout being in a FIPS-certified setting. The same
> scrutiny should apply to every source: examine the design, assumptions,
> evidence, and consequences for the end user.
> 
> The still-incomplete public record concerning NIST/NSA coordination and
> the answers given in this discussion make careful review more, not less,
> appropriate. I would also welcome explicit clarification of the IPR
> position, although the current drafts do not resolve it.
> 
> Comments that are not made by NIST have not brought clarity because any
> such analysis carries no weight about NIST's actual position. If NIST
> makes clear that we are free to hash `m` and retain the IPR waiver, we
> would be able to resolve the issue of excess authority preventing a
> stronger security posture, if it is desired. Do you see that they are
> unwilling to bring this clarity? If they were gagged as John Kelsey was,
> I would expect that bringing this clarity would be out of bounds. NIST
> is free to say otherwise and what they did say on the matter is
> contridicted by the public record. It could be credibly explained but
> NIST did not deem it worthy of their time.
> 
> The American cliché "good enough for government" is the phrase that 
> comes to mind here. Is that good enough for the IETF? No, it is not.
> 
>>> People should *especially* not be punished for the worst thing they 
>>> are suspected of doing, and especially if they did not do it.
>>>
>>> Even if they are guilty, they deserve a chance at redemption.
>>>
>>> Everyone deserves a fair shot at re-integration.
>>
>> For those who say TL;DR, the summary is that: IMO the ML-KEM I-D - and 
>> all I-Ds specifying KEMs- should normatively state which DRBGs are 
>> acceptable, and they should include informative text about the 
>> unfortunate risk of RNG-based kleptography when using KEMs outside DH 
>> hybrids.
> 
> I broadly agree, with the qualification if 'acceptable' is stated as a
> 'MUST' or a 'requirement imposed by NIST to achieve security' and that a
> hybrid does not help if both components depend on the same recovered RBG
> lineage.
> 
>> Ok then, here's my take:
>>
>> * Ideally we should have a practical, strong PQ Diffie-Hellman.  We do 
>> not. I agree in the strongest terms. Practical post-quantum 
>> constructions with genuine Diffie-Hellman-like contributory
>> behavior remain an important research goal.
> 
> MIKE seems interesting but I have not analyzed it, evaluated it, used an
> implementation in a deployment.
> 
> CTIDH is somewhat more familar to me and while there is literature that
> is relevant for the security in the quantum setting, I find it to be
> extremely promising.
> 
> CTIDH and related commutative group-action work are interesting in that
> respect. I help maintain an implementation released by an academic
> group, but I did not design CTIDH and make no claim that it is ready to
> replace standardized KEMs. In my own experimental use I combine it with
> X25519.
> 
> More generally, I would not deploy a comparatively young post-quantum
> construction without an independently generated classical component
> today. On balance I have decided that in at least two protocol withs no
> other PQC option available, a hybrid X25519 and CTIDH-512 or CTIDH-1024
> were better than X25519 alone. This protects against CTIDH failures
> today, and hedges against a future with quantum computers.
> 
>> * All KEMs are going to have this `m` problem in some fashion.  Is 
>> that a correct statement?  That makes all of them suitable for RNG- 
>> based kleptography. I do not think that all KEMs necessarily have the 
>> same problem. We need a precise property: can an adversarial recipient 
>> recover an unchanged, sufficiently large, ordered sample of the 
>> sender's RBG output?
> 
> ML-KEM clearly exposes that shape in the most risky way possible and it
> is unnecessary risk. To recap before we en-and-de-cap: `ML-KEM.Encaps`
> samples a 32-byte `m`, and a decapsulating peer that controls its
> implementation can retain the reconstructed `m'`. Third-round Kyber
> instead hashed `m` before using it [2][3]. Other KEMs and their uses
> have to be analyzed construction by construction; a ciphertext carrying
> a recoverable secret is not necessarily carrying raw generator bytes.
> 
> In addition to Kyber where everything is essentially equal except the
> hash in our discussion, sntrup761 is a useful contrast. It uses a
> structured fixed-weight ternary polynomial `r`, not a raw 32-byte `m`.
> In the reference sampler, many 32-bit random words are masked, sorted,
> and mapped into the ternary polynomial before `r` is used, and the
> shared key is derived by hashing its encoding [4]. The recipient can
> recover `r`, but `r` is not an unchanged contiguous generator block. The
> difference is extremely stark.
> 
> That does not prove immunity to every malicious or specially shaped
> RBG. It means only that the direct ML-KEM argument does not transfer
> unchanged. I made a preliminary attempt to recover a Dual_EC_DRBG block
> through this sampler and did not succeed. I would welcome a better
> analysis, especially from the sntrup761 authors: do you see a practical
> method for reconstructing a full Dual_EC output block from the existing
> fixed-weight sampler? The sntrup761 authors and implementations could
> also hash the RNG as Kyber did to make the comparison even easier.
> Regardless, NIST and a couple of other people may discuss the
> construction of `m` and KEMs in a way that would lead a reasonable
> person to believe a KEM always has this issue. However, it is simply not
> true. A KEM does not imply an `m`  must be composed of contiguous sample
> of the system RNG without transformation, otherwise. It is misleading
> and it is dangerous as I have shown with Dual_EC_DRBG as an example. In
> TLS this can lead to decryption of the connection, and future sessions.
> This is acceptable to NIST, and it should not be to the IETF.
> 
> This difference is one reason I remain comfortable with sntrup761x25519
> as a conservative OpenSSH option. The ML-KEM SSH exchange, like TLS,
> gives an unauthenticated client an opportunity to supply the
> encapsulation key and recover the server-generated `m` pre-auth; the
> actual risk still depends on the implementation's RBG, state separation,
> and generation order. This is a kind of landmine where it increases
> analysis work and where implementations may get it wrong. It is not the
> conservative choice that I would expect from the professionally prudent
> securtiy minds that brought us OpenBSD and OpenSSH.
> 
> It however entirely makes sense if OpenSSH needs to provide ML-KEM. I
> hope that they will ensure that `m` is hashed in practice but if not, it
> only further underscores why the NIST's decision process and their
> conclusion is unreasonable. OpenSSH is not only used in a FIPS-certified
> setting, and I highly doubt that NIST will promote the various DRBGs
> used by GNU/Linux, FreeBSD, NetBSD, and OpenBSD as qualified designs. I
> would welcome it as long as they did not impose unreasonable changes as
> they did with Kyber for `m` since those designs are what the world uses.
> 
>> For this reason I think we should have no RECOMMENDED=Y non-hybrid 
>> KEMs.  But I don't see why not have RECOMMENDED=N KEMs.
>> Interesting. I support hybrids as the conservative default, but the
>> hybrid label alone is not sufficient for this issue.
> 
> If the ML-KEM interaction permits recovery of an RBG state before the
> same state lineage generates the X25519 scalar, both components may be
> predictable. If the X25519 scalar was generated first and the RBG
> resists backtracking, that component may remain independent. Reseeding,
> per-connection state, buffering, and call order all matter.
> 
> A compact version of my current classification is therefore:
> 
> scheme       recoverable value            raw RBG block?
> ML-KEM       32-byte `m`                   yes
> Kyber r3     `H(m)`                        no
> sntrup761    fixed-weight ternary `r`      no
> 
> That table is deliberately narrow. I would not label every randomized
> signature, OAEP seed, DH exponent, or structured KEM secret as a "raw
> leak" merely because it depends on randomness; the transformation and
> recoverability must be analyzed. I have done most of that analysis on
> other IETF primitives but that is for a different email.
> 
>> * TLS 1.3 has insanely large nonces ('random'), and that's enough for 
>> RNG-based kleptography.
> 
> Agreed. TLS `Random` fields already create a broader public-output
> problem, and I regret not addressing it while TLS 1.3 was being written.
> I am preparing separate work on public and peer-recoverable RBG outputs
> across TLS, QUIC, MLS, SSH, IKE, and other protocols. That broader work
> should not prevent fixing an additional clean oracle now.
> 
>> therefore ML-KEM adds nothing much new *except* that when using a 
>> FIPS-140-3 validated module then ML-KEM can sneak a Dual_EC-style DRBG 
>> in through the back door even when the TLS 1.3 implementation would 
>> not otherwise use such a DRBG.
> 
> The word "except" is doing substantial work in your sentence. ML-KEM can
> expose an additional sample of the randomness used for secret generation
> even when an implementation separates or conditions other TLS-visible
> fields.
> 
> A successful sabotage mechanism should be reliable, economical, and
> plausibly deniable. The protocol should not make that job easier when a
> wire-compatible hash removes the direct structured sample.
> 
>> * We can insist that the choice of DRBG to use MUST be one of a set we 
>> approve of, and, impliedly, none of the ones we don't approve of.
>> Agreed in principle. We should state the actual requirement rather
>> than invent combined algorithm names. FIPS 203 requires fresh
>> randomness from an approved RBG, with the required security strength, 
>> under the SP 800-90 framework [2]. Hash_DRBG, HMAC_DRBG, and CTR_DRBG 
>> are the SP 800-90A mechanisms, but the requirement
>> also includes the entropy source and construction requirements in
>> SP 800-90B and SP 800-90C.
> 
> I would then state the separate `m` issue. The approved-RBG requirement
> is the primary layer; hashing `m` is a local layer that prevents this
> consumer from returning algebraically structured output to a peer when
> the primary assumption fails.
> 
> NIST and some of the IETF, such as myself, appear to have different risk
> tolerances on that point. NIST has publicly acknowledged the limited
> claim: hashing protected the KEM, while a broken RBG could still
> compromise the wider system. That is not an argument that the KEM-level
> protection has zero value but NIST agreeing that it has value, and that
> it is not valuable to _them_. Okay! I am glad that they did not present
> an attack as their original motivation to remove the hash. It is not a
> security issue to have the hash. It is good that we do not disagree on
> that point. The performance was also not a relevant concern. Their
> expressed concern is how they logically separate things in a FIPS-
> certified setting, and outside of that setting, they qualatiatively
> weakened the design and accept the consequences. This tells us their
> security posture, and it is less than the IETF should accept. These
> kinds of "logical" separations are how we had IPsec failures with
> Dual_EC_DRBG on the internet that allowed for full passive decryption
> through nonce leakage. This was reportedly exploited by the NSA and it
> is not in dispute. Juniper engineers probably deeply regret being
> tricked by that kind of mistaken protocol and implementation design.
> 
> The public record concerning NIST/NSA coordination is, and remains,
> incomplete. Materials produced through litigation appear relevant to
> statements made during this discussion. My understanding is that the
> litagion is ongoing and that production of documented related to NIST/
> NSA collaboration remains unfinished. I do not need to resolve that
> institutional history in this email. I do think NIST should answer
> concrete questions and publish enough of the record for independent
> evaluation. We could also wait for the lawsuit to finish but that is 
> likely to take a long time, so NIST could really help speed things up by 
> either stating their intention to 1) immediately and proactively produce 
> the documents in question and/or 2) directly engage here with the 
> understanding that if the documents later contridict them, they will be 
> on the hook. Both of those seem incredibly unlikely and that is why an 
> independent court has been involved to _force_ NIST to produce the facts.
> 
> Does it not concern you that the facts _already_ produced in that 
> lawsuit do not match the claims made by NIST on this very list?
> 
> If not, what would be the line for you? I ask so that when the lawsuit 
> is finished, we may do a proper retrospective analysis.
> 
>> The AES counter DRBG is plenty good enough. Which implementation?
> 
> CTR_DRBG can be a sound construction, but naming it does not guarantee a
> side-channel-resistant implementation. Cohney et al. demonstrated cache-
> based recovery against vulnerable table-based AES CTR_DRBG code in SGX,
> including state recovery, loss of forward security, and an end-to-end 
> TLS compromise [5]. This was an implementation attack, not a universal 
> break of CTR_DRBG. These kinds of failures are possible because NIST's 
> standards are below the security and the quality of the IETF's 
> standards. There are examples worth considering such as the constraints 
> described in NIST SP 800-90a.
> 
> The distinction matters. FIPS 197 specifies AES, but does not by itself
> require a constant-time implementation or test for secret-indexed table
> lookups. SP 800-90A specifies the DRBG construction, but cannot make a
> leaky AES implementation safe. Hardware instructions can reduce this
> particular risk, while introducing their own hardware and microcode
> assumptions. Would you believe that one of the findings in [5] as 
> presented in 2020 ( https://rwc.iacr.org/2020/slides/Cohney.pdf ) 
> included an OpenSSL FIPS module, the NetBSD kernel systemwide PRG (!), 
> mbedTLS _inside_ SGX, and also the nist_rng library. That includes a 
> FIPS-certified setting. Perhaps the FIPS-certified setting is not as 
> strong as the NIST advertising would have us believe?
> 
> NIST has not updated the corresponding standards in response to the 
> publication [5] as far as I am aware. I am happy to be corrected on this 
> point but if even NIST is able to get it right, maybe we should consider 
> this as a factor in their security posture?
> 
> I want to note as a matter of honesty that here, hashing `m` does not 
> save a system after the attacker has extracted the CTR_DRBG key; the 
> attacker can reproduce the hash. It does, however, address a different 
> failure class: algebraic structure in output that is otherwise handed 
> directly to the peer. Therefore the correct guidance is not "CTR_DRBG is 
> broken" or "the hash fixes everything." It is:
> 
> * exclude Dual_EC_DRBG and analogous structured generators;
> * require a securely implemented, prediction-resistant RBG;
> * require side-channel-resistant primitives and sound reseeding/state
>    management;
> * retain the local hash to avoid exporting raw structure;
> * even NIST's standards and certified FIPS modules get this wrong;
> * NIST updated their threat model in 2019;
> * NIST did not update the actual standards to require safe defaults!
> 
> The longer document should review Hash_DRBG, HMAC_DRBG, and CTR_DRBG,
> including side channels, fault attacks, entropy failure, reseeding, and
> state compromise, rather than treating an approved algorithm name as an
> implementation proof. The authors of [5] note that CTR_DRBG is not 
> provably secure, they note that Woodage and Shumow found problems with 
> HMAC_DRBG, and they encourage the use of Hash_DRBG.
> 
> Note that the authors in addition to the "Dual_EC Backdoor" they raise 
> the "Juniper Dual_EC Incident" they also raise the DUHK Attack on ANSI 
> X9.31.
> 
> So - lets recap that into some conclusions:
> - No: Dual_EC_DRBG (withdrawn (!))
> - No: CTR_DRBG (FIPS certifiable (!!) does not mean not exploitable)
> - No: HMAC_DRBG (see Woodage and Shumow's related work, and others)
> 
> Meanwhile, NIST says they are working on an updated SP 800-90A where 
> they announced a comment period ( https://csrc.nist.gov/pubs/sp/800/90/ 
> a/r2/iprd ) which closed in late 2025:
> 
>    Date Published: September 4, 2025
>    Comments Due: November 4, 2025 (public comment period is CLOSED)
> 
> Aside from the absurdly short comment period, NIST says that public 
> comments will be posted after the closing date. Nearly a year later, 
> that statement remains true as someday they may be posted. As of today, 
> the public comments have not been posted as far as I am aware.
> 
> Do you want to make a prediction about Hash_DRBG?
> 
>> This, however, may run into a problem where FIPS-140-3 validated 
>> cryptographic modules might not be configurable as to DRBG choice. 
>> However, it is enough to state this requirement.  We do not have a 
>> Protocol Police function.
> 
> Agreed. Accurately summarizing the NIST requirement and adding the
> right cross-references is sufficient for that part of the issue.
> 
>> * As long as there is one acceptable DRBG that can be selected, we can 
>> state a normative requirement and give useful advice regarding the 
>> dangers of RNG-based kleptography.
> 
> Agreed. I would list the approved constructions as examples, state
> the required properties, and explain the kleptographic failure mode.
> 
>> * I do suspect that all KEMs enable Dual_EC-style kleptography. And 
>> yet ML-KEM should be published.  Not because that's a good thing, but 
>> because -once more- the horse left the barn when the nonces (`Random`) 
>> were made more than large enough and when the codepoint registries 
>> were made Specification Required. I do not think the general 
>> conclusion about all KEMs follows, but I also do not think this is a 
>> reason to withhold ML-KEM indefinitely. My request concerns an 
>> avoidable, wire-compatible footgun and accurate
>> Security Considerations, not ML-KEM's lattice hardness assumptions.
> 
>> But also I'd have to see how recovering *one* `m` value would allow a 
>> kleptographer to steal *many* other clients' `m` values.
> 
> For Dual_EC_DRBG, the result depends on truncation and state
> management. With an untruncated 32-byte output, one `m` may be enough 
> for the trapdoor holder to recover the next state. With the standardized
> P-256 truncation, the attacker normally enumerates the missing bits and
> uses another output or other state information to identify the correct
> candidate [8]. Once a long-lived shared state is recovered, later
> outputs may be predicted until reseeding or separation defeats
> synchronization.
> 
> Or put simply: you draw 32 bytes from the sabotaged RNG, you transmit 
> it, you then draw 32 more bytes.
> 
> An adversary with the Dual_EC_DRBG trapdoor/secretkey(s) that receives 
> your first 32 bytes is able to predict the 32 bytes of the second draw, 
> even if you do not send them.
> 
> Would you like me to send you an implementation of this where you 
> control the trapdoor/secretkey(s)?
> 
>> * The large size of `Random` is still problematic.
> 
> Agreed. I call these public or peer-recoverable wire oracles. TLS 1.1,
> 1.2, and 1.3 all expose large `Random` fields, and other protocols can 
> inherit related risks through TLS or their own public randomness.
> 
> My broader survey remains preliminary because implementation choices,
> state sharing, sequencing, and authentication phase change the answer.
> If this attack class is deployed, however, the strategic value for mass
> collection and real-time decryption could be substantial.
> 
>> [Heavy trimming follows.]
> 
> Thank you for tolerating my verbosity. I will try to return the favor.
> 
>>>> * If the NSA wants to get burned again by playing the Dual_EC game 
>>>> again, let them!
>>>
>>> This is frankly, reckless. We should not be used unwittingly or be
>>> party to such folly.
>>
>> My personal advice: sometimes that is the smart play -- if you never
>> engage in tactical retreats thus badly losing some battles, you'll
>> exhaust yourself and lose the war.
> 
> I take the advice. My claim here is bounded: we should learn from
> Dual_EC_DRBG and treat it as the canonical public example of strategic
> cryptographic sabotage. The tactical compromise I can support is to
> publish after adding accurate RBG requirements and the `m` guidance,
> while moving the larger analysis to separate work.
> 
> I am exhausted, but that is another reason to turn the dispute into
> specific text rather than continue repeating it.
> 
>>>> * The NSA is not likely the monolith a social death penalty for it 
>>>> would have to presume.
>>>
>>> I do not understand this point but I agree that the NSA is not a 
>>> monolith. Part of asking the questions that I asked is that there are 
>>> NSA people I have directly spoken to who answered almost all of those 
>>> questions without a problem. I am not only talking about 
>>> whistleblowers but people whose job never involved cryptographic 
>>> sabotage.
>>
>> But you and/or others in these threads are treating all involved with 
>> NSA in regards to ML-KEM as monolithically motivated by the same 
>> interest in kleptography.  That amounts to treating the NSA as a 
>> monolith.  "It's supported by NSA pEoPlE!!" is basically the backup 
>> singers' line.
> 
> Thank you for clarifying. I do not infer a common motive from NSA
> affiliation, nor do I want an institutional blacklist. I would apply the
> same skepticism to Edward Snowden, Bill Binney, Thomas Drake, an NSA
> engineer, a NIST employee, a defense contractor, or an independent
> academic: examine what they propose, what assumptions they bring, how
> they answer questions, and what outcomes their position produces. Most 
> of all, I would want to examine their security posture.
> 
> Institutional background can still be relevant without making the
> institution a monolith. People with access to classified systems may
> know constraints or attacks that they cannot describe publicly. That can
> create blind spots even without malicious intent. Suite A is the obvious
> example: public reviewers cannot reason from secret knowledge they do 
> not possess, and a person who possesses it may be unable to explain why 
> or even _that_ a public design is unsafe.
> 
> Furthermore, they may feel that even if they _could_ do so, they do not 
> agree with thwarting large-scale adversaries if it would thwart their 
> favorite, civil-liberties respecting, honest, law-abiding, large-scale 
> adversary... who they consider more as a friend in any case.
> 
> The solution is not personal exclusion. It is transparent threat models,
> conflict disclosure where applicable, independent review, explicit
> assumptions, and technical mitigations that do not depend on trusting a
> person's institutional role. It is also important to look at the 
> results. NIST's modified Kyber grants a cryptographic oracle in over a 
> dozen protocols where the protocols are layered.
> 
> Example: your Signal client uses ML-KEM in TLS, and again in the Signal 
> e2ee ratchet. Neither are required to be FIPS-certified, to put it mildly.
> 
> My own principle is simple: I will not support cryptographic sabotage or
> an accommodation designed to preserve it or that allows for it as an 
> acceptable consequence of an imposed change against the express wishes 
> of the cryptographic primitive's designer(s). I will support technically
> sound protections even when they protect people or institutions hostile
> to me. RFC 7258 says pervasive monitoring is an attack; the relevant 
> IETF value is to reduce harm to the end user [12].
> 
>>>> * There is no technical content regarding ML-KEM to back this up.
>>>
>>> I could easily believe that you were aware of these issues before the 
>>> discussions on this list. Were you?
>>
>> Some of them.
> 
> Agreed. As exhausting as it has been, the discussion has produced a
> clearer technical record and some real convergence.
>>> For example, were you aware that you could do this kind of thing, 
>>> including recovering `m`?
>>
>> I believe my earlier response (and the above) should make it clear 
>> that I am.  Above is a fuller treatment of this issue.
> 
> 
> Yes, now it is clearer. I was asking about before the discussion
> because the point is subtle and was absent from the drafts' Security
> Considerations and from several early responses. That suggests a gap in
> our protocol-analysis process worth fixing.
>>> Do you think that the removal of a hash function to enable it is not 
>>> "technical content" when that single design choice was made exactly 
>>> to counter this kind of thing?
>>
>> Not sufficient to stop publication.  Instead it is sufficient to argue 
>> that the choice of DRBG must be limited.
> 
> 
> Then we agree that it is technical content. I am not asking for 
> nonpublication as an end in itself. If the DRBG restriction includes the 
> reason for it, the recoverability of `m`, and the Appendix C.1 tradeoff, 
> we are close to agreement.
>>> Are you really buying the argument from NIST where they made it worse 
>>> and accept that as a fact, over what, ~300-1500 cycles?
>>
>> With a non-kleptographic DRBG it seems fine. 
> 
> Does that still hold with the cited research showing that the current 
> (not even including Dual_EC_DRBG!) NIST DRBG have non-trivial security 
> failures?
> 
> Does it concern you at all that a practical full state recovery over the 
> network against TLS was shown for CTR_DRBG in a FIPS-certified setting 
> and NIST has so far only updated their _threat model_? If the authors 
> did not catch that two month call for comments _five years later_, will 
> NIST even address these issues?
> 
> Regardless, as of now, it does not seem fine to me. Updating the threat 
> model is absolutely hilarious, I am sure that is very reassuring to 
> impacted parties.
> 
>> I agree that the risk of inserting a kleptographic DRBG is real, but 
>> not publishing is not
>> really a good answer.
> 
> 
> We agree that the kleptographic-RBG risk is real, and I agree that
> nonpublication is not the only answer.
> 
> I still would not call the unhashed design equally safe. It is
> qualitatively weaker than the same construction with one additional
> hash because it relies entirely on the RBG and its implementation. The
> hash was present specifically to tolerate one class of upstream failure.
> 
> CTR_DRBG illustrates the distinction between an algorithm and a deployed
> system. The Cohney et al. work used cache leakage in a vulnerable AES
> implementation to recover DRBG state and compromise TLS [5]. That does
> not show that CTR_DRBG is kleptographic, but it does show that "use an
> approved DRBG" is incomplete implementation guidance. Similar questions
> exist for Hash_DRBG and HMAC_DRBG. What the relevant research literature
> says about side channels, fault injection, entropy failure, reseeding, 
> (RNG) state compromise, and malicious implementation all deserve
> systematic analysis.
> 
> We should define the attack classes carefully. Young and Yung's SETUP
> model is a natural starting point for deliberate kleptography, while
> side-channel and fault attacks may belong in adjacent categories. The
> engineering response can still be systematic:
> 
> * write down each attack strategy and the required capabilities;
> * distinguish design, implementation, supply-chain, and compulsion
>    failures;
> * test whether each construction and implementation resists it;
> * record mitigations and residual risk; and
> * set a minimum profile for protocol use.
> 
> Hardware acceleration is not a magic boundary. AES instructions, RDRAND,
> and SHA extensions reduce some software-side channels but add
> assumptions about hardware, microcode, firmware signing, and update 
> channels. Those assumptions can fail through ordinary bugs or 
> sophisticated compromise.
> 
> The point is not that every extreme scenario is occurring; it is that
> protocol guidance should not confuse a standardized algorithm with an
> immutable, side-channel-free implementation. Also, IETF should not push 
> a standard that requires FIPS-certified setting as a general matter when 
> the general case was made weaker and imposed a new dependency to acheive 
> security: the FIPS-certified setting!
> 
> I have preliminary experiments in which an ML-KEM interaction supplies a
> useful observation point against a deliberately vulnerable table-based
> CTR_DRBG implementation. I do not present that as a general break or a
> finished result. The research from 2019/2020 still generally applies.
> 
> The immediate conclusion remains modest: require a defensible RBG,
> require secure implementation and state management, and hash `m` so this
> particular peer interface does not export raw structure. The longer-term
> work can determine what additional requirements are needed for each
> SP 800-90 construction.
> 
> Also just to restate the obvious: we are really discussing some text in 
> a text file that is _advice_ to implemnters who are not building in a 
> NIST-certified setting. Those implementers better understand the 
> situation and are required to diligently follow NIST's standards. Yes, 
> that still leads to certified implementations being broken in some cases 
> and that is _also_ NIST's problem, not the core concern that we face.
> 
>>>> There is only the 1DES key weakening and the Dual_EC adventure,
>>>
>>> This is not a fair or accurate accounting of the history. Even if you 
>>> skip the Clipper Chip, export cryptography and all related attacks in 
>>> SSL/TLS, and many other related matters, the issue of Dual_EC_DRBG 
>>> amazingly *still* ships today in one of the most popular Java 
>>> libraries in the world. It also ships ML-KEM. We agree about 1DES, of 
>>> course.
>>
>> Clipper was an overt attack on the public. There are at least two 
>> distinct issues.
> 
> Clipper was an overt policy attack, but policy opposition was not the
> whole story.
> 
>  From memory, Prof. Dr. Matt Blaze had to find a novel technical failure 
> in the Escrowed Encryption Standard: the 16-bit LEAF authentication 
> check could be searched so that a device retained strong Skipjack 
> encryption while bypassing the escrow mechanism [9]. This was not a 
> cryptanalytic break of Skipjack itself; it was a break of the key-escrow 
> protocol surrounding it. That distinction strengthens, rather than 
> weakens, the lesson that expert technical review can defeat a 
> government-mandated access design. Skipjack itself followed the 1DES 
> pattern with the 80-bit key and 64 bit block choices by the way.
> 
>> The 512-bit modular DH group precomputation thing was not a covert 
>> attack on the standards process.
> 
> It is not only about 512-bit DH, of course.
> 
> I understand the perspective that export controls and weak 512-bit 
> groups were not, by themselves, covert manipulation of the standards 
> process.
> 
> Noteworthy however is that "covert" depends on a lot of assumptions 
> about people's understanding of what certain technical framing means in 
> a given context. The GSM cryptographic weaknesses may well have been 
> understood by some telecom technician but most non-technical users of 
> the phones most certainly did not always understand.
> 
> They were nevertheless policy-created weaknesses whose practical 
> consequences were not understood by most users of products marketed as 
> secure. We should classify the history precisely without minimizing the 
> harm.
> 
>> Perhaps only Dual_EC was a covert attack on the standards process.
> 
> I do not think Dual_EC_DRBG exhausts the documented history of
> SIGINT enabling or weakened communications standards.
> 
> GSM is one example. TETRA is another important case: the secret TEA1 
> algorithm,  used in critical-communications systems, reduced an 
> advertised 80- bit key to 32 effective bits and was only publicly 
> understood after reverse engineering [10]. The researchers did not 
> establish who inserted the weakening or whether it was exploited, but 
> the result is directly relevant to how we evaluate secret or nationally
> constrained cryptographic designs. TETRA is highly relevant to European 
> security.
>> ML-KEM might be a covert attack, but not on the standards process 
>> because the codepoints were always going to be assigned, and of course 
>> we're discussing the possibility that ML-KEM is kleptography so much 
>> that everyone who needs to know that it could be, does.
> 
> The public, undeniable fact is that FIPS 203 removed the hash that
> Kyber said protected against flawed randomness [2][3]. I am not claiming
> that ML-KEM is itself a covert attack. I am saying that the change opens
> a direct hidden-structure failure mode and that an approved algorithm
> name does not eliminate implementation or side-channel risk and that is 
> when we are speaking about the FIPS-certified setting. Outside of that 
> NIST's change makes our lives harder which is not something that we are 
> required to accept and to pass on to others. The NetBSD kernel wide DRBG 
> CTR_DRBG example from [5] was impressive.
> 
>> Clipper being an overt attack, and ML-KEM maybe a covert attack, you
>> can see that Clipper would be easier to defeat -- the whole public
>> could see it.
> 
> Agreed: the removal is not covert. Appendix C.1 records it. The
> technical effect is also public: relative to third-round Kyber, ML-KEM
> no longer has that local safeguard against flawed randomness. Experts
> therefore have a responsibility to explain the tradeoff and the
> assumption that replaced it.
> 
>>>> And again, if your fears turn out to be true, then you win a big
>>>> prize: more egg on the NSA's face.
>>>
>>> This does not follow. It took over a decade for John Kelsey to come 
>>> out with his public apology tour. It only happened because one person 
>>> blew the whistle and essentially killed himself for us to know about it.
>>
>> But the egg landed on their face much earlier.  Apologies and non- 
>> apologies are merely the acknowledgement
> 
> Agreed that the reputational damage began earlier but it was also
> paid in disrespect to people who raised the findings as a concern.
> That pattern repeats here as a variation on the theme but this time,
> the attack may be a fact to some but now instead of being in doubt,
> it is dismissed as old news or as irrelevent or unexploitable, and so on.
> 
> The important point is not whether an institution eventually apologizes; 
> it is how long users remain exposed before the technical problem is 
> acknowledged and fixed. Shumow and Ferguson's 2007 rump-session 
> observation, and Blaze's Clipper work, are reminders that early warnings 
> deserve serious technical treatment.
>>>> Thus I don't think there is anything we can do regarding `m` other 
>>>> than give advice for non-FIPS implementations -- perhaps we should 
>>>> do that much,
>>>
>>> That sounds like the discussions have moved you!
>>
>> Then you might like the above.  Except you might not because it 
>> doesn't move the needle as much as you seem to want.
> 
> I will take the movement and thank you for several intense but useful
> days of discussion.
> 
>>>> but that seems like something TLS and IETF should say much more 
>>>> generally in a BCP rather than in each Internet protocol RFC that 
>>>> somehow needs RNGs.
>>>
>>> Or maybe, not? I guess I also agree with you that we need a draft 
>>> about the overall issue. Would you be interested in co-authoring such 
>>> a draft?
>>
>> I cannot easily co-author I-Ds [for reasons], not with celerity.  I 
>> can comment and suggest text.
> 
> Thank you. Comments and suggested text would be genuinely useful; I
> could take responsibility for an updated draft but I think the draft 
> authors should resolve the outstanding technical issues that they see as 
> valid. That tells us about the security posture that they wish to 
> advance in the IETF. That applies _equally_ to the hybrid and the pure 
> ML-KEM drafts.
> 
>>>> * You and others are destroying your credibility and good will 
>>>> towards yourselves and towards the IETF by really reaching in your 
>>>> arguments against ML-KEM.
>>>
>>> That is a fair point. [...]
>>
>> That sounds like the discussions have moved you as well :)
> 
> Yes. The discussion has moved me toward a narrower, more actionable
> position where now I see that NIST's current DRBG offerings are 
> _exceeding dangerous_ in the TLS context. Simply presenting them
> without qualification seriously misrepresents the risks as a general
> solution. I remain concerned that credibility and tone sometimes
> displace technical disposition, but I should also make my own arguments 
> easier to assess and harder to dismiss.
> 
>>> I observed an intense desire for conformity and harmonization in the 
>>> form of a popularity contest. There are a few people in the 
>>> discussion who broke through that wall. Quite a few people 
>>> demonstrated that when it came down to a factual point that they have 
>>> a duty to the truth. I personally respect that a lot more than the 
>>> parasocial shaming behavior and the foot dragging.
>>
>> Last October I was on DJB's side.  His pounding the table got me to 
>> abandon that side -- there were no real arguments other than "they've 
>> done it before" and "of course they'd do it again".  Now there's the 
>> `m` matter, and regarding that see the above.
> 
> The cases for and against pure PQC and hybrids are broader than those
> two slogans. I also understand why perceptions of repetitive or abrasive 
> presentation can cause readers to disengage. This is in part a big
> structural failing of the NIST process and it is a problem in the IETF
> as well.
> 
> At the same time, process cannot substitute reaction to style for a
> technical disposition. NIST's participation raised factual questions
> about the history and rationale of the change, and the answers did not
> resolve all of them. My earlier comments also waited years for a partial
> response. That history helps explain the frustration, although it does
> not excuse unnecessary heat from any participant.
> 
> I will focus this reply on the concrete convergence: define the RBG
> requirements, explain `m`, record the Kyber/FIPS change, and state the
> mitigation.
> 
>> I really want to emphasize that DJB's manner of argument is a 
>> tremendous turn-off.
> 
> 
> I hear you. It should not determine whether a reproducible technical
> claim is true. The working group needs both professional communication 
> and a process that tracks substantive objections to a clear disposition.
>>> We should still try to do good things for the betterment of all 
>>> people, even if they're unappreciative.
>>
>> Some people, when faced with a difficult war, choose a hill to die on, 
>> then die on it.  Others fight until it's time to retreat to live
>> to fight another day.  Martyrs don't win wars.
> I understand. The useful response is not martyrdom but converting the
> issue into durable text and reproducible work. While it remains in our
> power, we should endeavor to create that centered around the End User's 
> security. The End User that is not in the FIPS-certified setting 
> especially as NIST has the FIPS-certified setting covered. It does not 
> exactly inspire confidence that in the FIPS-certified setting the 
> certified CTR_DRBG could be exploited to remotely extract the CTR_DRBG 
> AES keys over a network through TLS. They have it covered alright! That 
> security posture is their choice.
> 
>>> This mistake by NIST should be undone in so much as we should not go 
>>> along with something when the research data shows that it is dangerous.
>>
>> Look at it from NIST's point of view: that hash merely extends the 
>> DRBG, and via FIPS they mandate DRBGs, so if the hash is important 
>> then it should be included in the DRBG or the DRBG should be designed 
>> so it's not needed because the DRBG is not necessary.
> 
> I understand that position. But a protocol-level hash is not merely
> "more DRBG." It enforces a property at a separate boundary: the peer
> receives `H(x)` rather than the DRBG output `x`. That matters precisely
> when the upstream RBG assumption fails, and not every TLS deployment is
> inside the FIPS validation model.
> 
>> Thus my [new] position is that we should limit the set of acceptable
>> DRBGs. 
> 
> We may agree on limiting acceptable RBGs if phrased as NIST's 
> requirements that must be imposed to acheive their notion of security.
> Because approved construction names do not by themselves guarantee a
> safe implementation, I would add implementation guidance here and
> develop the broader requirements in a separate document. I was shocked
> when I realized that the literature piles up but the FIPS standards do 
> not keep pace, rather the _threat model_ is updated! TLS should become 
> stronger and stronger as we learn new things, and the threat model 
> should become _stronger_ as adversary capabilities improve. The purpose 
> of TLS is to provide _security_ not a false sense of security, after all.
>>> Yes, I understand the criticism that this appears to be contrived 
>>> because you do not use /dev/hwrng or similar interfaces but I wonder 
>>> what would change your mind?
>>
>> The `m` issue did change my mind, as you noted.  Just not to the point 
>> of opposing publication.  Rather, I propose normatively limiting the 
>> choice of DRBGs to ones we believe are not kleptographic.
> 
> I do not oppose publication once the immediate issues are written down
> or referenced accurately.
> 
>>> For example, the Cavium SIGINT enabling - Cavium has a kernel driver 
>>> for their hwrng and it presents as /dev/hwrng which does not 
>>> transform the output. This kind of CPU is used in "security" devices.
>>>
>>> Please consider that NSA claims it as a SIGINT Enabling Success.
>>
>> If you have a TLA-in-the-box attack, you have bigger problems.  And by 
>> you I mean we, naturally.
> 
> My question is whether "if" is the right prior and what evidence would
> change it.
> 
> The Cavium reporting shows a knowledge-and-choice problem: users may 
> rely on hardware and firmware they cannot meaningfully audit, and 
> hardware RNG interfaces can feed operating-system entropy pools or be 
> consumed directly. A compromised source is a system-wide problem, but 
> that is not a reason to remove cheap local barriers at protocol 
> boundaries. The reason for the removal is not required for security and
> it re-introduces an entire class of security failures. Some large-scale 
> deployments could easily remove that hash and no one will know, so in my 
> view those kinds of deployments should not impose their extreme 
> privilege on the rest of us. Most people, unlike the large defense 
> contractors who mentioned hashing was going to impact their bottom line 
> or the environment, do not have thousands of engineers working from the 
> top to the bottom on their systems. Most people do not have absolute 
> confidence in their full computing systems, they must make assumptions 
> about trust which will change in a big way with this PQC transition.
> 
>>> Would you believe that someone does the wrong thing with that kind
>>> of stack and does so in a way that harms security?
>>
>> Certainly possible, even likely.
> 
> I am glad we agree.
> 
>>>> * We know they will go to IEEE if we don't publish.  IETF is much 
>>>> more open, so if we abdicate our remit to more closed SDOs,
>>>> what will you have achieved with this social death penalty?
>>>
>>> I do not understand this part - the draft can go to the ISE if 
>>> consensus can't be reached. Deb should not be pushed out of the IETF, 
>>> and no one should be ostracizing her. This holds for anyone in these 
>>> discussions, even convicted felons.
>>
>> See above (at the very top).
> 
> Understood.
> 
>>> That said - if the authors of the draft want to take it elsewhere and 
>>> publish it, especially because the WG won't rubberstamp something and 
>>> want to add some basic security considerations, I would say that is 
>>> their right. I note that they are welcome to integrate the text and 
>>> then I think most objections would be handled. Most of us can't edit 
>>> the draft by merging a pull request. I have the sneaking suspicion 
>>> that that if I open the pull request that it would not be merged. If 
>>> I am wrong, I would do the work.
>>
>> Would you settle for publishing with a normative requirement that the 
>> DRBG used to generate `m` be one we approve of?
> 
> Almost. I would settle on publication with a normative RBG requirement
> plus text that explains why `m` matters and recommends restoring the
> hash. The RBG restriction and the hash address different layers. The
> same is true of CTR_DRBG: choosing the construction does not excuse a
> leaky table-based AES implementation. That leaky table-based AES 
> situation is catastrophic and that is for a current NIST DRBG. At the 
> very least we should also normatively cite the (ever weaker?) NIST 
> threat model!
> 
>>>> Really, pick your fights carefully!
>>>
>>> I take your point(s) and I respectfully submit that I observe what
>>> appear to be some oversight in a few of your priors. I appreciate
>>> many of your points though.
>>
>> Have I covered all points now?
> 
> Probably, yes. Remaining is some discussion above as well as the task to 
> produce the exact text.
> 
>>> We all have a duty to resist and none of us have a duty to obey. We
>>
>> I agree with this.
> 
> Good to know, I am glad.
> 
>>> have no requirement to simply go along with such things, especially 
>>> if we think will lead to harm to the End User. With deep respect to 
>>> the actual Indigenous people of the world: we the Indigenous 
>>> Cryptographers of the Internet SHOULD help the End User
>>> to resist targeted and mass surveillance and indeed, we MUST treat
>>> pervasive monitoring as an attack [0].
>>>
>>> To paraphrase Bill Hicks: there is a war on your privacy and each 
>>> time that you protect your privacy with strong encryption, you're 
>>> winning it.
>>
>> On so many fronts.  The whole age verification stuff is clearly aimed 
>> at ending anonymous and pseudonymous posting so as to force self- 
>> censorship on people.
> 
> Agreed. The claimed benefit of broad age-verification mandates does
> not justify the resulting surveillance, identity linkage, and chilling
> of anonymous or pseudonymous expression.
> 
>>> [0] A term the NSA has given *us* and we should claim it, and wear
>>> it with pride to stand in solidarity with other Indigenous peoples
>>> of the world.  Note: "the fact that NSA/CSS makes cryptographic
>>> modifications to commercial or indigenous cryptographic
>>> information security devices or systems in order to make them
>>> exploitable" is "Top Secret" - https://www.spiegel.de/ international/ 
>>> germany/inside-the-nsa-s-war-on-internet-security- a-1010361.html
>>
>> But also public.  And something we basically knew to expect.
> 
> Yes. The history is public enough that surprise is no longer a
> reasonable response. The standards question is which concrete
> engineering lessons we apply now.
> 
> Kind regards,
> Jacob Appelbaum
> 
> [0] https://datatracker.ietf.org/doc/html/rfc8730
> 
> [1] https://datatracker.ietf.org/doc/html/rfc5742
> 
> [2] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
> 
> [3] https://pq-crystals.org/kyber/data/kyber-specification-
> round3-20210804.pdf
> 
> [4] https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf
> 
> [5] https://eprint.iacr.org/2019/996
> 
> [6] https://datatracker.ietf.org/doc/html/rfc4086
> 
> [7] https://datatracker.ietf.org/doc/html/rfc8937
> 
> [8] https://hovav.net/ucsd/dist/juniper.pdf
> 
> [9] https://www.mattblaze.org/papers/eesproto.pdf
> 
> [10] https://www.midnightblue.nl/research/tetraburst
> 
> [11] https://cr.yp.to/antiforgery/cachetiming-20050414.pdf
> 
> [12] https://datatracker.ietf.org/doc/html/rfc7258
> 
> _______________________________________________
> 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]

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQQwbnhHy1kPJkWsM6fk2On5l6gz3QUCalu1TgUDAAAAAAAKCRDk2On5l6gz3et0
AP9FsL3BcftBIVfELnhf8qIUp4RKYx1/bpJOrrlmjPFyjgD+Lt4mQdj8K8IxHkx0aZ4cSuVGeDpG
4r/f+ChjF4ay+AQ=
=kT8Z
-----END PGP SIGNATURE-----