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 solo ML-KEM in TLS. The chart also covers solo 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 solo PQ creates security risks (statement) (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) (statement) (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) (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) (statement)

      • pro: "ML-KEM and ML-DSA are a lot easier to implement securely than their classical alternatives" and will have "exceedingly few bugs" (statement) (statement) (statement) (statement)

        • con: no, millions of ML-DSA keys will be breakable in 2027 because of severe software vulnerabilities (statement) (statement) (statement) (statement) (statement) (statement) (statement) (statement) (statement) (statement)

          • pro: bugs in ML-DSA software are generic "Fiat–Shamir" bugs that can also happen in ECC software (statement) (statement)

            • con: no, we've already seen ML-DSA bugs that aren't "Fiat–Shamir" bugs and don't have ECC analogues; more to the point, ECC+ML-DSA software has lower risk than ML-DSA software (statement) (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 and ML-DSA do not have secretly keyed backdoors (statement) (statement) (statement)

        • con: the same argument applies to RSA-512, SIKE, and many other broken cryptosystems (statement) (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 solo PQ (statement)

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

          • con: one pro argument says that everyone should move eventually from ECC+PQ to solo 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 solo ML-DSA:] people objecting to solo ML-KEM shouldn't object to solo 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"; "As soon as the breakage becomes publicly known, we can expect implementations to switch to a different algorithm"; "your vulnerability begins and ends with your verifier starting and stopping to trust the public key"; "while still difficult to detect, signature keys being broken is detectable, especially if this type of breakage happens at scale" (statement) (statement) (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"; NSA said that its "QUANTUMINSERT attacks were 'highly successful' starting in 2005; those attacks were not publicly detected until the Snowden documents revealed them in 2013"; "Revocation sometimes reduces the damage caused by forgeries. But forgeries remain tremendously damaging, and ECC+PQ reduces this damage compared to solo PQ" (statement) (statement) (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 solo ML-DSA:] no, we can and should skip ECC+PQ for signatures; "Hybrid classic + post-quantum authentication makes no sense" (statement)

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

      • pro: ECC+PQ creates the problematic software engineering/testing complexity of combining each ECC option with each PQ option (e.g., ECC1+PQ1, ECC1+PQ2, ECC1+PQ3, ECC2+PQ1, ECC2+PQ2, ECC2+PQ3, ECC3+PQ1, ECC3+PQ2, ECC3+PQ3); "combinatorical explosion"; "Support all of the schemes? Probably not feasible"; "significantly delay PQC migration, to the extent that industry would miss European 2030 deadlines" (statement) (statement) (statement) (statement)

        • con: no, the software engineering/testing complexity is almost entirely inside the individual options; the combinations are simple and easy to automate; each ML-DSA implementation is thousands of lines of code (statement) (statement) (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., solo-ML-KEM draft version 07 (12 February 2026) includes "simplicity" (statement)

    • pro: using solo PQ avoids "balkanisation through too many choices"; with ECC+PQ the "cost is now that we have more algorithms"; "18 composite key types ... complexity"; "increase the number of options" (statement) (statement) (statement) (statement)

      • con: no, solo PQ increases TLS complexity by forcing more options (see above)

    • pro: [specifically regarding solo 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 solo 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; solo 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 solo 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 and 3GPP and O-RAN need TLS to support solo ML-KEM, at least as an option (statement) (statement) (statement) (statement)

        • con: no, IEEE 802.11bt and 3GPP and O-RAN have no engineering need for TLS to support solo PQ; their statements do not address ECC+PQ vs. solo PQ, never mind providing a rationale for solo PQ; internally, IEEE 802.11bt was told that NSA requires solo PQ, but has not decided yet whether to comply; 3GPP and O-RAN were told that the TLS WG was considering publishing some documents as drafts rather than as RFCs (statement) (statement) (statement) (statement) (statement) (statement)

  • pro: everyone should move eventually from ECC+PQ to solo 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"; "Hybrid constructions are, by design, a temporary measure" (statement) (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"; the "only benefit" of ECC+PQ is protection if the PQ part "is classically broken before the CRQCs come" (statement) (statement) (statement) (statement) (statement) (statement)

      • con: even after a billion-dollar quantum computer starts breaking thousands of ECC keys per year, there will still be many more broken PQ keys rescued by ECC+PQ for the next decade (statement) (statement) (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) (statement)

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

  • pro: [specifically regarding solo ML-DSA:] we urgently need post-quantum signatures in TLS; solo 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 solo PQ (see above), and provides post-quantum signatures in TLS with less risk than solo PQ (see above)

  • pro: [specifically regarding solo ML-DSA:] using solo ML-DSA rather than ECC+ML-DSA avoids "trivial attacks on strong unforgeability"; "take a non-hybrid signature and a broken secondary scheme and glue them together into a hybrid signature the signer has never signed"; "significant practical vulnerabilities" (statement) (statement) (statement) (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) (statement) (statement) (statement)

      • pro: if a firewall blocks a user by blocking a certificate then "strongly unforgeable" signatures would stop the user from modifying the certificate to evade the firewall; consider CVE-2026-25793, blocklist evasion in an overlay networking tool called Nebula

        • con: no, "strongly unforgeable" signatures do not stop users from modifying certificates (statement) (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

  • pro: [specifically regarding solo ML-DSA:] "an attacker starts to be able to take a hybrid signature and rip it apart into a separate, valid signature" (statement)

    • con: no, that's an "attack" against a strawman "property", not an attack against TLS

  • pro: [specifically regarding solo ML-DSA:] "ML-DSA and SLH-DSA have a context parameter in their specification, and if you are trying to describe a hybrid, you have to define around that" (statement)

    • con: this has nothing to do with the question of ECC+PQ vs. solo PQ

• con: the spec is procedurally improper

  • con: the spec is driven by an attacker (statement) (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 solo PQ; the push for solo PQ 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 solo-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) (statement)

  • con: BCP 72 asks for due diligence in "describing all known or foreseeable risks and threats to potential implementers and users"; this spec violates that (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)

  • con: the spec is controversial, including objections from many people, including unanswered objections (statement) (statement) (statement) (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) (statement) (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) (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: these objections were stated before (statement) (statement)

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

    • pro: these particular objections weren't stated before; "That sort of argument would I think have carried more weight if clearly articulated and adhered to from the outset"; "you’re shifting the goalposts" (statement) (statement)

      • con: no, these particular objections were already stated years earlier and still haven't been answered (statement) (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 solo PQ 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 was a side debate on the TLS mailing list about whether ML-KEM key reuse should be prohibited. At least one of the votes for the spec was 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". 2026.06.25 update: Added the latest, and switched terminology from "non-hybrid PQ" to "solo PQ".]