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: SIKE was publicly broken after being applied to tens of millions of user connections; half of proposed PQ cryptosystems have been mathematically broken; more PQ implementations have been broken (statement)

    • 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: 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" (statement) (statement)

      • con: no, lattices have lost many bits of security and continue to lose security; some lattice proposals have been broken (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: [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." (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"; also, breaking signatures is often more valuable for the attacker than breaking encryption

  • con: since we have ECC+PQ anyway, adding a PQ option makes TLS more complicated (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: 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 version 07 (12 February 2026) now includes "simplicity" (statement)

    • con: no, the spec increases TLS complexity (see above)

  • 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" (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 some updated sources for estimating 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 ML-DSA is the only way to get that done

    • con: hybrid ML-DSA provides post-quantum signatures in TLS with less risk and negligible extra cost

• 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 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.]