Hi everyone, I am leaving the TLS list as a direct result of these ridiculous emails from Jacob.
Goodbye, Nadim Kobeissi Symbolic Software • https://symbolic.software > On 18 Jul 2026, at 5:48 PM, Jacob Appelbaum <[email protected]> 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]
