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.

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) (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)

      • 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)

    • pro: lattices are very well studied (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" (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)

      • 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

        • 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)

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

    • 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)

  • pro: everyone should move eventually from ECC+PQ to non-hybrid PQ; "hybrid PQ/T is clearly a transitional mechanism" (statement)

    • pro: ECC is useless since quantum computers will break ECC; the ECC part of ECC+PQ is useless for the same reason (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)

      • 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)

• 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)

    • pro: versions 06 (11 February 2026) and 07 (12 February 2026) of the spec have new text

      • con: previous circularity was fixed, but motivation sections of versions 06 and 07 are still short and unjustified (statement) (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)

• 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

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

    • 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)

      • 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)

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.