The cr.yp.to blog

2026.02.21: NSA and IETF, part 6: The structure of the debate. #pqcrypto #hybrids #nsa #ietf #chart

You've sometimes made a list of pros and cons regarding a hard decision, right? Maybe the decision turns out to be easy in the end; maybe not. Either way, making the list is useful in thinking things through.

There's a slightly modified type of list that I like to use in understanding debates about a proposal: instead of just making a linear list of claimed pros and claimed cons, I make a chart that shows that claim B is, at least conceptually, a response to claim A. These responses can be supporting arguments ("A — for example, B") or counterarguments ("A — no, B" or "A — yes, but B"). When multiple arguments and/or counterarguments are addressing the same point, I'll include that point in the chart, whether or not it was stated explicitly, so that all of the related arguments are tied to that point.

Bringing related points and examples and counterpoints together makes them easy to compare. I find this easier to use than the commonly recommended "pros on the left, cons on the right". This structure also makes it easy to spot unanswered arguments.

As an illustration of this structure, this blog post charts the debate about a particular proposal, the NSA-driven proposal for IETF to publish an RFC specifying usage of non-hybrid ML-KEM in TLS. The chart also covers non-hybrid ML-DSA, where the debate is almost exactly the same, but the chart notes a few differences.

In this chart, "pro" means an argument for the proposal; "con" means an argument against the proposal; indenting B under A means that B is a supporting argument for A (if A and B are both pro or both con) or that B is a counterargument to A (if A and B are on opposite sides).

Here we go!

• con: the spec does damage

  • con: weakening normal ECC+PQ to non-hybrid PQ creates security risks (statement) (statement) (statement) (statement) (statement) (etc.)

    • con: half of proposed PQ cryptosystems have been mathematically broken; for example, SIKE was publicly broken after SIKEp434 was applied to tens of millions of user connections (statement)

    • con: more PQ implementations have been broken (statement)

      • pro: "we will end up with secure implementations" of PQ (statement)

        • con: hopefully, yes, but ECC+PQ reduces the damage done by attacks in the meantime

    • pro: ECC+PQ makes no sense; it is "cognitive dissonance to simultaneously argue that the quantum threat requires immediate work, and yet we are also somehow uncertain of if the algorithms are totally broken. Both cannot be true at the same time" (statement) (statement)

      • con: asking for certainty is not competent risk management; ECC+PQ sensibly tries to reduce damage from breaks of the PQ part and from quantum attacks; it's wearing your seatbelt and trying to make sure the car doesn't crash (statement) (statement)

    • pro: lattice risks are negligible

      • pro: lattices are very well studied and were "fully vetted" through "a full decade of entirely open, international analysis and debate over the security of quantum-resistant cryptography through the NIST PQC process"; "ML-KEM was fully vetted through this process"; "No new cryptanalyses have been offered"; nobody has pointed to a "specific attack against lattices"; "The lattice candidates survived" (statement) (statement) (statement) (statement)

        • con: actually, some of the lattice candidates in the NIST PQC process have already been broken (including Compact LWE, HILA5's IND-CCA2 claim, and Round2); furthermore, all of the remaining lattice candidates have lost many bits of security and are continuing to lose security (statement) (statement)

        • con: since December 2023, Kyber/ML-KEM software has had emergency security patches for KyberSlash 1, then KyberSlash 2, then Clangover (statement) (statement)

      • pro: ML-KEM does not have a secretly keyed backdoor (statement)

        • con: the same argument applies to RSA-512, SIKE, and many other broken cryptosystems (statement)

      • pro: NSA can't possibly have an attack against ML-KEM; NSA says they'll use ML-KEM; "if you really think ML-KEM is broken, then yes, the NSA has successfully undermined the IETF in order to make their own systems less secure"; "I regard the inclusion of ML-KEM-1024 in CNSA2 as a serious endorsement" (statement) (statement)

        • con: NSA secretly said DES was weak enough to break, but publicly said they would use it (statement)

        • con: if NSA has an ML-KEM break then for their own data they'll use something else, no matter what they claim publicly (statement)

      • pro: nobody outside NSA will use this, so any breaks of ML-KEM will be "not impacting anyone else" (statement) (statement) (statement)

        • con: no, an RFC will lead to usage outside NSA; applications often choose whatever sounds like the most efficient solution; some of the pro arguments are actively encouraging broader usage of non-hybrids (statement)

          • con: one pro argument says that some constrained environments can afford non-hybrid PQ but not ECC+PQ (see below)

          • con: one pro argument says that everyone should move eventually from ECC+PQ to non-hybrid PQ (see below)

    • pro: there are security risks other than PQ security failures

      • con: this is not an argument against reducing the damage of PQ security failures

      • pro: "The most dangerous implementation vulnerabilities are things like spectre, row hammer, or good old buffer overflows" (statement)

        • con: these risks are relevant to the PQ-vs.-ECC+PQ decision only to the extent that there are buffer overflows etc. specifically in the ECC software; history shows many more PQ security failures, and that's where hybrids reduce the damage (statement)

      • pro: "by far the biggest risk when it comes to signatures is not in the algorithms themselves, but implementers either forgetting to verify, ignoring the verification result, or forgetting to check that the message actually attests to the thing they wanted attesting for" (statement)

        • con: there is a security problem of some callers failing to verify, but the PQ-vs.-ECC+PQ decision is orthogonal to that (see below) and instead reduces the damage from PQ security failures

        • pro: as an "example" of this "biggest risk", "just this week: Critical flaw in wolfSSL library enables forged certificate use" (statement)

          • con: that's not an example; it's not the caller failing to verify; it's a counterexample; it's a severe bug in some algorithm implementations; ECC+PQ reduces the damage from such bugs

    • pro: [specifically regarding non-hybrid ML-DSA:] people objecting to non-hybrid ML-KEM shouldn't object to non-hybrid ML-DSA since "the concerns are quite different, because there's no timewarp. Future breaks are not a concern now."; "There is no analogous 'harvest now, decrypt later' against signature schemes"; the hybrid "benefit is a little lower than hybrid key exchange due to the lack of store-now-decrypt-later risk"; there is "limited security benefit anyway given there is no HNDL equivalent"; "the blast radius for signatures has a strict end with revocation of the key" (statement) (statement) (statement) (statement) (statement)

      • con: close to 100% of the algorithms breaking post-quantum cryptosystems and post-quantum software work on current computers; an attacker who figures out how to break ML-DSA won't have to wait for "future breaks"; breaking signatures is often more valuable for the attacker than breaking encryption; breaking TLS signatures allows breaking TLS encryption; "we are back to the old 1990's world of no protection against active man-in-the-middle attacks"; "If your protocol allows a man-in-the-middle attack, it is REALLY bad"; revocation can be useful in reducing the damage, but is not an argument against other ways to reduce the damage (statement) (statement)

  • con: since we have ECC+PQ anyway, adding a PQ option makes TLS more complicated by forcing more options (statement)

    • pro: yes, but a particular implementation can avoid implementing ECC and can thus become simpler

      • con: no, those implementations will fail to interoperate with already-deployed ECC+PQ and with the mandated ECC baseline for TLS

        • pro: those failures don't happen for private implementations in an isolated environment (statement)

          • con: private implementations in an isolated environment have no need for an IETF spec; IETF has a "fundamental" rule that "IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user"

    • pro: [specifically regarding non-hybrid ML-DSA:] no, we can skip ECC+PQ for signatures

      • con: no, "multiple national information security authorities have set the use of PQ/T hybrids as the standard" (statement)

• pro: the spec has benefits

  • pro: the spec is needed for regulatory compliance, "regulatory frameworks that require standalone post-quantum key establishment"; "hybrid doesn't necessarily work for everyone" (statement) (statement)

    • pro: the spec is needed for compliance with NIST standards (statement)

      • con: no, NIST allows ECC+PQ (statement)

    • pro: the spec is needed for compliance with CNSA 2.0 (statement) (statement)

      • con: no, the official NSA documents on CNSA 2.0 say "hybrid solutions may be allowed or required due to protocol standards"; so far NSA's push for this spec consists of unofficial actions by NSA employees (statement)

    • pro: another "regulatory reference" is CSE ITSP.40.111 (statement)

      • con: no, CSE ITSP.40.111 is merely stating "recommended cryptographic algorithms" (statement) (statement)

      • con: also, CSE ITSP 40.111 does not prohibit hybrids (statement)

  • pro: an RFC is needed for the spec so that others can use the spec; "Many vendors will only support ML-KEM-only TLS if there is, specifically, an RFC from IETF specifying such"; "most SDOs, including the IETF, have significant concerns about using the current Internet-Drafts as long-term normative references" (statement) (statement)

    • con: that's a circular argument; the point of the opposition is to dissuade usage of this spec (statement)

  • pro: the spec improves security; ECC+PQ "increases attack surface by adding another code base" (statement)

    • con: no, ECC+PQ forces attackers to break ECC and PQ (statement)

  • pro: the spec decreases TLS complexity; rationale for, e.g., non-hybrid ML-KEM draft version 07 (12 February 2026) includes "simplicity" (statement)

    • pro: using non-hybrids avoids "balkanisation through too many choices"; with ECC+PQ the "cost is now that we have more algorithms" (statement) (statement)

      • con: no, non-hybrids increase TLS complexity by forcing more options (see above)

    • pro: [specifically regarding non-hybrid ML-DSA:] for double-signing with ECC+PQ the "complexity cost is vastly higher than hybrid key exchange" since "Composite keys leak all over the API and application/configuration layer" and these keys complicate "X.509 authentication"; "Having to store and apply two keys at the same time will, as Filippo pointed out, propagate throughout the entire library"; "enormous API complications"; "makes the cost of this security blanket much higher" (statement) (statement) (statement) (statement)

      • con: no, this supposed complexity difference does not exist; the API and the calling code use ECC+PQ in exactly the same way that they would use non-hybrid PQ; "Of course it would internally have multiple keys, but that's no different from existing algorithms whose keys have multiple components (e.g., RSA)"; "in no case would you have to explicitly worry about multiple keys at the application layer"; "I implemented Composite ML-DSA in an OpenSSL provider and it Just Worked. No X.509 changes. No TLS changes."; "crazy amount of mis-understanding of composites on display here" (statement) (statement) (statement) (statement)

  • pro: the spec decreases cost; non-hybrid PQ is smaller and faster than ECC+PQ; hybrids require "ad hoc encodings"; "pure-mlkem is the obviously correct solution if you want high-performance solutions" (statement) (statement) (statement)

    • con: the cost difference is minor (statement)

      • pro: some constrained environments can afford non-hybrid PQ but not ECC+PQ; "constrained environments where smaller key sizes or less computation are needed" (statement)

        • con: this is implausible: ML-KEM keys are 800/1184/1568 bytes; X25519 keys are only 32 bytes; communication and computation costs of X25519 are negligible compared to communicating ML-KEM keys and ciphertexts (statement) (statement)

      • pro: high-frequency trading needs the smallest possible latency (statement)

        • con: that's irrelevant; this is a key-exchange spec; key-exchange costs do not affect trading latency (statement)

      • pro: there are "deployments where legacy middleboxes reject larger hybrid key shares" (statement, later removed without an erratum)

        • pro: this is reported in a 2024 blog post, a 2025 blog post, and a 2025 draft

          • con: no, the second source says that legacy-middlebox problems with PQ were fixed years ago; the first and third sources don't claim legacy-middlebox problems; also, none of the sources claim that 32 extra bytes are an issue (statement) (statement)

      • pro: IEEE 802.11bt needs non-hybrid ML-KEM, at least as an option (statement) (statement) (statement)

        • con: no; IEEE 802.11bt has no engineering need for non-hybrids; IEEE 802.11bt has been told that NSA requires non-hybrids, but has not decided yet whether to comply (statement) (statement)

  • pro: everyone should move eventually from ECC+PQ to non-hybrid PQ; "hybrid PQ/T is clearly a transitional mechanism"; "bridging technology"; better to "make the future transition easier"; deploying hybrids would require a "second large-scale engineering effort to migrate to pure ML-KEM sometime later" and would "consume literal years of my life" (statement) (statement) (statement) (statement) (statement)

    • pro: ECC is useless since quantum computers will break ECC; the ECC part of ECC+PQ is useless for the same reason; ECC "isn't doing much now and won't do anything at all, in just a few years"; "hybrids are pointless" once there is a "CRQC" (a "cryptographically relevant quantum computer"); ECC+PQ "will offer no real benefit over PQ once a CRQC exists" (statement) (statement) (statement) (statement) (statement)

      • con: even if quantum computers end up breaking an ECC key for only 1 million USD, should we make each connection 1 million USD cheaper to attack? (statement) (added notes on one way to estimate electrical costs, ignoring hardware-manufacturing costs: https://arxiv.org/abs/2603.28846 estimates 2¹⁹ qubits running for 1/3 hour to break one key; https://arxiv.org/abs/2304.14344 estimates 6 watts per qubit; 2²⁰ watt-hours costs about $100 USD in electricity)

      • con: even if ECC is eventually useless, this cannot justify avoiding ECC now; removing ECC from ECC+SIKE would have expanded the damage of the SIKE break by exposing ECC+SIKE users to immediate non-quantum attack (statement)

    • con: there are many ways that ML-KEM can end up not being the eventual choice (statement)

  • pro: [specifically regarding non-hybrid ML-DSA:] we urgently need post-quantum signatures in TLS; non-hybrid PQ is the only way to get that done; ECC+PQ is a "distraction delaying the urgent migration to PQC signatures"; "Keeping systems vulnerable to quantum attacks out of fear of implementation faults isn’t a good trade-off"; "the industry should stop letting the perfect be the enemy of the deployed" (statement) (statement) (statement)

    • con: ECC+PQ is fully specified, has negligible extra cost compared to non-hybrid PQ (see above), and provides post-quantum signatures in TLS with less risk than non-hybrid PQ (see above)

  • pro: [specifically regarding non-hybrid ML-DSA:] ML-DSA avoids "trivial attacks on strong unforgeability" (statement)

    • con: these "attacks" are changing signatures for the same message; that's not an attack against TLS; the TLS ecosystem already relies heavily on signature systems that allow these irrelevant "attacks" (statement)

      • pro: there could be a problem if non-TLS protocol designers need "strong unforgeability" but copy this aspect of TLS

        • con: that's the argument to spend a few more lines of code in ECC+PQ signatures to avoid these "attacks" and various other "attacks"; even without this protection, potential failures in other protocols are less important than failures in TLS

• con: the spec is procedurally improper

  • con: the spec is driven by an attacker (statement)

    • con: this violates BCP 188 ("IETF Will Work to Mitigate Pervasive Monitoring") (statement)

    • con: obeying demands from NSA is unprincipled; how often does IETF obey demands from China and Russia? (statement) (statement)

      • pro: no, there's no favoritism here; "the NIST competition was international, and Kyber was developed by an international team" (statement)

        • con: participation was international but selection was controlled by the U.S. government; NSA's secret input to NIST specifically promoted lattice submissions and specifically promoted Kyber (statement)

        • con: the dispute at hand is not about whether to allow ML-KEM but whether to allow non-hybrids; the push for non-hybrids is coming from NSA (statement)

  • con: the spec's motivation section is short and unjustified (statement) (statement) (statement)

    • pro: versions 06 (11 February 2026) and 07 (12 February 2026) of the non-hybrid ML-KEM spec have new text (statement)

      • con: previous circularity was fixed, but motivation sections of versions 06 and 07 are still short and unjustified (statement) (statement)

  • con: the spec has not gone through the FATT process (statement)

    • pro: there has been security analysis so "some review by the FATT" should allow publication (statement) (statement)

    • pro: the chairs say that FATT review is not required for this spec (statement)

  • con: the spec does not explain why it is violating the broad rationale for hybrids stated in other IETF specs (statement)

  • con: the spec is outside the scope of the official TLS WG charter (statement)

  • con: the spec is missing a patent disclosure regarding the ML-KEM patents (statement)

  • con: there are unanswered objections to the spec (statement) (statement)

• pro: objecting to the spec is procedurally improper

  • pro: the spec is not a law; there are no protocol police; people are allowed to do what they want; the spec is not a standard; the spec is not recommended; the spec says "RECOMMENDED: N" (statement) (statement)

    • con: this will have very little effect on the damage done by an RFC; purchasing managers rarely read the RFCs that they are requiring; "Users will take the reputation of the IETF and understand this as a recommendation, whether it says = N or not"; "I think it's clear that many regard the publication of an RFC by the TLS WG as a form of endorsement, even when Recommended=N" (statement) (statement)

  • pro: objecting to the spec at this point is procedurally improper

    • pro: any damage that could be caused by issuing the spec as an RFC has already been caused; "pure ML-KEM variants are and will be used whether or not a final RFC is published"; non-publication would merely "dilute the standing of the IETF TLS WG"; "the rest of the world will use it anyways"; "non-publication is now pointless" (statement) (statement) (statement) (statement)

      • con: one pro argument says that "Many vendors will only support ML-KEM-only TLS if there is, specifically, an RFC from IETF specifying such" (see above)

      • con: people understand publication of an RFC as IETF endorsement (see above)

    • pro: the chairs already declared consensus to publish in November 2025, so objections are improper beyond the formal appeal already filed (statement) (statement)

      • con: not true; after the chairs issued "last call" for publication of version 05 in November 2025, there were many objections and no consensus, as the chairs officially admitted in December 2025: "In summary, we do not have consensus to publish the document as is." (statement) (statement) (statement)

      • con: the cited appeal is actually regarding an April 2025 chair declaration of consensus to adopt the spec, not regarding what happened in November 2025 (statement)

    • pro: objections have been stated before (statement)

      • con: mostly, yes, but each "last call" for objections has been ignoring previous objections; the chairs should instead be tracking objections (statement)

    • con: discouraging discussion is contrary to the goal of getting this right (statement)

  • pro: issuing the spec as an RFC is an opportunity to include caveats regarding the spec, so people who object to non-hybrids should support the spec; otherwise "counterproductive loss of opportunity to recommend due caution" (statement) (statement) (statement)

    • con: it's better to reject the RFC and, if there's consensus on caveats, issue those caveats as a separate document (statement)

There's also a side debate about whether key reuse should be prohibited; at least one of the votes for the spec is conditional on adding such a prohibition. That debate isn't covered here.

[2026.03.23 update: Added some further arguments and counterarguments to the chart. 2026.04.10 update: Added the latest, and expanded to cover ML-DSA. Corrected the note on electrical costs. 2026.04.13 update: Added links for a few new statements of earlier arguments. 2026.04.18 update: A few more arguments and counterarguments. Added some combined headings such as "pro: lattice risks are negligible".]