This page presents quotes, with links for verification, of various talking points that showed up from proponents of solo PQ during a limited-time voting process on the IETF TLS mailing list (starting 24 June 2026, ending 8 June 2026). This page also summarizes my reaction to those talking points.
See also my chart of arguments and counterarguments for links to more detailed statements from proponents and opponents, with proponents ignoring important objections. Presumably the talking points that showed up during a limited-time voting process were what proponents believed were their most convincing arguments.
"Even well-understood algorithms like ECC can have implementation vulnerabilities"
— Nobody is claiming that ECC always saves the day. We're just saying that using ECC+PQ instead of solo PQ reduces the damage in case of security failures in the PQ part.
"What if ECDH implementations have bugs?"
— Same strawman as previous talking point.
— "Do we trust the car to not crash? If yes, keeping seatbelts is an unnecessary complexity. If no, we shouldn't be using the car at all." What a bizarre argument.
We hope ML-KEM is adding protection against quantum computers. However, in case of security failures in the ML-KEM spec or ML-KEM software, we continue also using ECC, instead of stupidly throwing ECC away.
— Same risk-management error as previous talking point.
— This is repeating the risk-management error from the previous two talking points.
— This was in response to Roberto Avanzi, one of the Kyber/ML-KEM designers, posting the following: "In my opinion the issue is not implementation errors, they can be avoided with the right discipline. But, as a codesigner of ML-KEM myself I would not trust using it exclusively: what if it gets broken mathematically and in the classical computational model (I.e. non-quantum)? Hybrid is better, and the additional time used by ECC is not significant."
The "should've worked harder back then" retort is missing the point. There are many things we do to reduce risks: for example, designers try to avoid security problems, cryptanalysts try to find security problems, and integrators use affordable defense-in-depth mechanisms such as ECC+PQ. These processes don't eliminate risks. Being honest about the risks of each layer helps protect users.
— 36% of the submissions selected by NIST in 2019 for the second round were broken by 2023. Was NIST selecting snake oil?
Seeing how often post-quantum systems are broken after 1 year, after 2 years, etc. gives us an idea of the chance that a break will escape cryptanalytic scrutiny each year, and gives us an idea of the risk that remains several years later.
The same statement applies to lattice systems in particular. Out of the lattice submissions to NIST, we saw breaks of, e.g., Compact LWE, HILA5's IND-CCA2 claim, and Round2. The remaining lattice candidates lost many bits of security and continue to lose security. Nobody is claiming that a feasible attack against the ML-KEM spec has been published; but there's a risk, and preserving ECC is a low-cost way to reduce the resulting damage—along with reducing the damage from ML-KEM software vulnerabilities.
— RC4 is not new. It was published in the 1990s, and its security is the topic of nearly 100 attack papers. It was broadly deployed in TLS (and in other applications).
Does this extensive study and attention mean that RC4 was secure? No. RC4 kept losing security, for example turning out to be feasible for academics to break as deployed.
Various lattice-based cryptosystems were introduced in the 1970s as "knapsack" systems and were broken. The first versions of NTRU in the 1990s were broken. LWE from 2005 is not directly comparable to NTRU since LWE isn't a public-key encryption system, but the 2010 Lindner–Peikert LWE-based cryptosystem proposed dimension 256 as supposedly taking "about 2150 operations" to break; after many attack improvements, the latest academic attack demos are already beyond dimension 200.
During the NIST competition, Kyber was a moving target. For example, Kyber-2019 eliminated the Kyber-2017 key compression because Kyber's previously claimed "security proof only applies to a variant of round-1 Kyber that does not compress the public key". Kyber-2020 made further changes to try to "increase the Core-SVP hardness". These changes weren't supplements to the earlier versions of Kyber; they were replacing the original versions, abandoning the original Kyber-2017 security claims.
Will ML-KEM-512 be broken? Will ML-KEM-1024 be broken? We don't know. Each lattice-based cryptosystem tries to avoid the security screwups that plagued earlier lattice-based cryptosystems, but this isn't easy to get right. A proper risk analysis has to look not just at the age of lattice-based cryptography but at how much damage cryptanalysis has done to lattice-based cryptography.
— Huh? Where's the supposedly extensive list of cryptanalysis papers specifically focusing on Kyber during NISTPQC?
There were papers on general advances in lattice attacks such as "Progressive lattice sieving", reducing the security levels of Kyber and other lattice submissions. Papers such as "On the impact of decryption failures on the security of LWE/LWR based schemes" were somewhat more specific—"decryption failures" are an attack avenue that had been eliminated by some lattice submissions—but still broader than Kyber.
— Outright denial of the value of delaying attacks. Amazing.
Obviously what we want to achieve with PQ rollout is having the data protected not just today but far in the future. But, in case we screw that up, ECC adds tremendous value in (1) delaying attacks until attackers have quantum computers, (2) limiting those attacks to the attackers who can afford quantum computers, and (3) limiting the number of broken keys because of the per-key expense of quantum attacks.
— Same mistake as previous talking point.
— Same issue as the previous two talking points. There are big differences between (A) betting at even odds on quantum attacks publicly breaking one key by 2033, (B) saying that quantum attacks will definitely break a key by 2033, (C) saying that quantum attacks will break all of the keys for that cryptosystem by 2033, and (D) saying that the cryptosystem is useless today.
— This argument is flawed on two levels.
First, the vulnerabilities that have been discovered in cryptographic specifications and in cryptographic software are only occasionally "NOBUS backdoor" vulnerabilities such as the Dual EC vulnerability. Arguing that ML-KEM is secure because it doesn't have a NOBUS backdoor is as dumb as arguing that RSA-512 and SIKE are secure because they don't have NOBUS backdoors. This has been pointed out before.
Second, the NSA director publicly claimed in 1979 that NSA had "endorsed the use of DES for the encryption of national security-related information, including selected classified information". But secret NSA documents showed that NSA knew that DES was "weak enough" to break. DES was in fact remarkably cheap to break even with 1970s technology. Anyone leaping from "NSA says they're using it" to "NSA is using it" to "NSA doesn't know how to break it" to "it's secure" is falling prey to a marketing trick. This is something else that has been pointed out before.
— I've been consistently recommending ECC+PQ since 2016. Solo PQ is a weakening of ECC+PQ.
If the TLS WG issues an RFC on solo PQ in TLS then many of the users who would otherwise have used ECC+PQ will end up using solo PQ instead. Many decisionmakers will understand the issuance of an RFC as IETF endorsement—a statement by IETF that solo PQ has acceptable quality—and will choose solo PQ. Any decisionmakers who look more closely at the RFC will be bombarded with, e.g., a claim to be "consensus of the IETF community" (the current draft doesn't say this but it's automatically stamped on every WG-issued RFC), one-sided claims regarding "ML-KEM's IND-CCA security" etc., and unfounded insinuations that ECC+PQ poses problems for "performance" and for "operational constraints". Furthermore, the same overt NSA pressure that led to this spec in the first place isn't going to suddenly stop with issuance of an RFC; it will continue into pressuring companies to switch to solo PQ, the same way that it has pressured companies before.
— "Integration logic between ML-KEM and ECC"? What ietf-tls-ecdhe-mlkem does is concatenate the ML-KEM and ECC outputs. This integration is just a few lines of code. Those lines reduce the damage from bugs and other security problems in many more lines of code for ML-KEM. It makes absolutely no sense to use the possibility of bugs in a few lines of code as an argument to skip mitigations for bugs in many more lines of code.
— If a bug produces accidental reuse of ML-KEM public keys across connections, why would this be "noticed and immediately fixed"? This type of attack would trigger failed connections, but it's common practice for software to retry after failures. Claiming that the attacks would be noticed and that bugs would then be fixed doesn't change the fact that the attacks succeeded in the meantime.
Proponents of solo PQ write that "even a single broken key per month can be catastrophic" in the context of saying that quantum attacks matter. How can they ignore the damage done by bugs?
More fundamentally, arguing that "many" vulnerabilities are avoided is a reasonable argument for avoiding key reuse but not a reasonable argument for removing other defenses.
A study of hundreds of vulnerabilities in cryptographic libraries found that 1/8 of "cryptographic" vulnerabilities were severe. Any competent reader can easily pick an example of a vulnerability that isn't severe; but some vulnerabilities are severe.
— Someone could reply this way to any safety objection to any proposed option: "You're complaining about the security of using RSA-512? We've addressed this by saying that we're just standardizing this option, not recommending it!"
This is content-free. It's not addressing the objection; it's dodging the objection.
ECC+PQ "doubles the FIPS/compliance validation effort and timeline."
— False. NIST SP 800-227 explicitly approves a "key combiner" where "at least one shared secret" is approved: i.e., NIST's approval of PQ implies NIST approval for ECC+PQ, even if the ECC part is unapproved. This has been pointed out before.
— This is some extra layers around the same basic mistake as the previous talking point.
The certification requirements for U.S. government purchasing of any "cryptographic module utilized within a security system protecting sensitive but unclassified information" are specified in FIPS 140-3, "Security requirements for cryptographic modules". For key establishment, FIPS 140-3 approves whatever is approved in NIST SP 800-140D. NIST SP 800-140D says that the "current list of CMVP-approved sensitive security parameter generation and establishment methods" is at https://csrc.nist.gov/projects/cmvp/sp800-140d. That page redirects to https://csrc.nist.gov/projects/cryptographic-module-validation-program/sp-800-140-series-supplemental-information/sp800-140d. That page, in turn, approves two types of KEMs: anything in FIPS 203 (i.e., ML-KEM); and anything in SP 800-227 (so ECC+ML-KEM, whether or not the ECC part is approved).
— False. The question of whether a PQ signature system is internally ECC+PQ or solo PQ has no connection to the PKI layer. This has been pointed out before.
A separate point is that the specific proposal on the table is about encryption, not signatures. I think it's useful to consider both together since the core objections to solo PQ apply simultaneously to encryption and signatures; but it's structurally wrong to try to argue for solo ML-KEM by waving at issues that are obviously signature-specific.
— In fact, defense-in-depth mechanisms are popular in computer security, popular specifically in cryptography, and frequently used specifically in the context of multiple layers of encryption.
For example, symmetric cryptography makes pervasive use of extra layers of encryption as a security margin protecting against some layers being broken: extra "rounds" of encryption, hashing, etc. Sometimes the layers are of different types: for example, the MARS cipher uses "a mixed structure, where the top and bottom rounds are designed differently than the middle ones".
Similarly, there is a long history of defense-in-depth proposals within public-key cryptography, such as NESSIE's 2003 recommendation of "double encryption using ACE-KEM and RSA-KEM", i.e., ECC+RSA. But proposals to combine public-key systems typically ran into cost objections that prevented broad deployment.
A decade later, after many improvements in the costs of computation and communication, cost objections were still limiting SSL/TLS security levels, in particular for RSA and for non-ECC DH. Google was just starting to upgrade from 1024-bit RSA. Software was often limited to 1024 bits for DH. Uri Blumenthal (from "MIT Lincoln Labs", which, despite its university-associated name, is a fully owned subsidiary of the United States Department of Defense) wrote on the TLS mailing list that he would "vote against anything (ephemeral DH-related :) larger than 1536 bits".
The situation today is different. ECC+PQ has only negligible cost beyond solo PQ. This hasn't stopped proponents of solo PQ from insinuating that ECC+PQ is too expensive, but this time the numbers don't back them up.
— No IETF WG ever approved those documents! IETF has a back-door "ISE" mechanism to produce RFCs, and these RFCs snuck in through that mechanism. Readers who think that "RFC" means "Internet standard" are fooled into thinking that IETF endorsed those documents. IETF insiders claim that readers are supposed to notice that these RFCs say "The RFC Editor has chosen to publish this document at its discretion" whereas documents issued by WGs claim to be "consensus of the IETF community".
— I recommend that SSH implementors provide sntrup761x25519-sha512 (also under its original sntrup761x25519-sha512@openssh.com name). It's the most widely deployed post-quantum option in SSH, and not supporting it means unnecessarily giving SSH plaintext away to attackers. From this perspective, it's good to see IETF's endorsement of sntrup761x25519-sha512 in SSH.
Meanwhile solo ML-KEM in TLS is a pointless security regression from ECC+ML-KEM in TLS, so I object to usage of solo ML-KEM in TLS, and I object to IETF endorsement of solo ML-KEM in TLS. It's wrong to describe this objection as merely saying that ML-KEM "does not need an RFC"; the objection is that the endorsement conveyed by an RFC will be actively harmful, leading to security damage that would not have occurred otherwise.
"Hybrid fanatics stole my goldfish."
— Liar, liar, pants on fire. Meanwhile there are actual records of NSA having "signals intelligence as its primary mission", NSA spying on Americans, NSA opposing "improvement of cryptography", NSA proposing a weak Data Encryption Standard, NSA threatening cryptographers, NSA proposing a weak Digital Signature Standard, NSA creating export-law exceptions to solidify the market for weak cryptography, NSA pushing a chip with weak cryptography, NSA fighting multiple court battles to try to preserve the export controls, NSA proposing a weak standard for random-number generation, NSA bribing companies to use that standard, NSA spying on even more Americans, NSA hacking into devices, and NSA's SIGINT Enabling Project having a quarter-billion-dollar-a-year budget to "covertly influence and/or overtly leverage" standards and other systems to make them "exploitable" while "the consumer and other adversaries" think that "the systems' security remains intact".
Okay, I admit that "Hybrid fanatics stole my goldfish" is not an exact quote. My main goal in this page is to address things that sound like they're actually addressing the content of the proposal on the table.
— ML-KEM-768 sends an 1184-byte key plus a 1088-byte ciphertext. Bleeding-edge ML-KEM-512 is 800 bytes plus 768 bytes. Adding X25519 adds just 32 bytes to the key and just 32 bytes to the ciphertext. As for "memory", the stack space used temporarily during an X25519 computation is smaller than, and reuses, the stack space used temporarily for an ML-KEM computation. The computational costs of X25519 are negligible compared to the communication costs of the ML-KEM key and ciphertext. In short, continuing to use X25519 adds negligible cost compared to the costs of ML-KEM, never mind comparisons to the overall costs of TLS.
Looking at the numbers shows how difficult it is to argue that TLS can afford solo PQ but can't afford ECC+PQ. If anyone had found even a single verifiable example of a TLS application in that situation, we would have been hearing endless references to that example by now, rather than hearing one unfounded insinuation after another.
— IETF says the following rule is "fundamental": "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." Saying that NSA wants something is not an engineering argument and is not finding the best solution for the whole Internet.
— The WG has already endorsed ECC+ML-KEM. Hopefully the ML-KEM part protects against "store now, decrypt later" quantum attacks. The ECC seatbelt reduces damage whenever ML-KEM security fails.
The proposal on the table is to have the WG also endorse solo ML-KEM, i.e., endorse removing the ECC seatbelt. That's what people are objecting to, often by giving examples of ways that ML-KEM security could fail.
The proposal isn't to replace a different PQ choice with ML-KEM. Arguing that ML-KEM is better than another PQ choice (for example, because it's available now) is irrelevant to evaluating the merits of the proposal that's actually on the table.
— The TLS standard mandates implementing ECC. A TLS implementation that doesn't support ECC will very frequently fail to interoperate. The proposal on the table isn't to change the requirement to implement ECC; proponents of this proposal have repeatedly emphasized that they're not asking everybody to switch to solo PQ. Instead the proposal is to add solo PQ as an option (and the core objections are to the security risks of allowing this option). So, no, this proposal does not allow skipping whatever ECC maintenance might still be needed.
Example of proponent emphasizing that they're not asking everybody to switch to solo PQ: "Hybrid and Pure have different risk profiles and trade-offs. It makes sense to let the user pick what suits best." Astoundingly, that's the same person as the proponent miscrediting this proposal with skipping ECC maintenance. (Uri Blumenthal again.)
Note that there are other inconsistencies in the case for solo PQ. This is the obvious reason that the spec avoids stating its supposed rationale: doing so would force that rationale to reach consensus.
"It is not unreasonable to argue that a smaller code base is easier to evaluate (non hybrid)."
— Same confusion as previous talking point. TLS already mandates ECC; the proposal for IETF to allow solo PQ is not a proposal to remove ECC from the TLS code base.
"With hybrid, one is significantly increasing the size and complexity of a hardware implementation"
— No, this is the same confusion as the previous two talking points.
— The proposal at hand is not to have "oversight". The proposal is to issue ietf-tls-mlkem as an RFC.
There have been previous claims that people opposing solo PQ should support an RFC on solo PQ as an "opportunity to recommend due caution". But issuing warnings as a separate document is much better than burying warnings inside a document that readers will typically understand as endorsement. This has been pointed out before.
— The proposal at hand is for IETF to endorse solo PQ. No country has a right to impose decisions on IETF. Allowing IETF decisions to be influenced by governments violates IETF's promise to its funding sources that IETF is a "neutral standards body because participants cannot exert influence as they could in a pay-to-play organization where members, companies, or governments pay fees to set the direction"; instead "IETF standards are reached by rough consensus, allowing the ideas with the strongest technical merit to rise to the surface".
— SIKE is not an isolated case. Some further examples to contemplate: DSA was published in 1991, was standardized in 1994, and was withdrawn in 2001 (in favor of a modified system confusingly also called "DSA") because it was suddenly shown vulnerable to an attack with a "workfactor of 264". OCB2 was published in 2004, was standardized in 2009, and was suddenly shown in 2018 to be efficiently breakable. XCB was published in 2007, was standardized in 2010, and was suddenly shown in 2024 to be efficiently breakable.
Praising each public break as a success of finally attracting enough attention is missing the point. The point is that the community sometimes takes many years to find an attack.
The first version of Kyber was published in 2017. There were then various changes before the final ML-KEM. Claims that Kyber/ML-KEM was "fully vetted" during the NIST competition are contradicted by papers in October 2025, December 2025, and February 2026 each claiming to remove another few bits from the ML-KEM security level.
Of course we hope that the cost of attacks will stabilize at an acceptably high level, but if there is a devastating break then ECC will often save the day.
— "If you are aware of a weakness in ML-KEM, please enlighten us."
Starting in December 2023, the reference software for Kyber/ML-KEM went through three rounds of security patches for KyberSlash 1, KyberSlash 2, and Clangover. The majority of Kyber/ML-KEM libraries issued patches for KyberSlash. Looking at this history, and at the broader history of hundreds of vulnerabilities in cryptographic libraries, makes clear that we're going to see further bugs and timing leaks in ML-KEM software, some of which will be exploitable in the TLS context, even if the security level of the ML-KEM specification stabilizes. The point of keeping ECC is to reduce the damage from whatever ML-KEM security failures happen.
— My 30 June 2026 blog post covers a variety of flaws in this statement, but let me highlight just two. First, most of the cryptosystems in the literature with worst-case-to-average-case reductions are broken cryptosystems. Second, looking merely at "known cryptanalysis" is failing to manage risks. We're using ECC+PQ to reduce the damage from attacks that aren't known today, whether the attacks are against PQ specs or against PQ software.
— This is incorrectly conflating concrete costs with asymptotics. But let's go along with this error: let's ignore every subexponential speedup, and let's assume that asymptotic exponents accurately predict concrete costs. The statement has more basic problems: the word "mildly" is not a defensible summary of the actual numbers, and the "stable for nearly a decade" claim is simply false.
What the phrase "mildly decreased" is actually talking about, without giving any numbers and without giving any URLs for readers to check, is a drop of exponents from 0.415 (2008 Nguyen–Vidick and 2010 Micciancio–Voulgaris) to 0.384 (2011 Wang–Liu–Tian–Bi), then 0.378 (2013 Zhang–Pan–Hu), then 0.337 (2014 Laarhoven), then 0.298 (2015 Laarhoven–de Weger), then 0.292 (2015 Becker–Ducas–Gama–Laarhoven).
An improvement of some number by an average of 0.02 per paper might not sound very big. But these are exponents, and the cumulative impact of this series of improvements was that the 2010 exponent was 42% higher than the 2015 exponent.
We continually see people claiming that 128-bit security is just fine. If that were to drop by a factor 1.42 then it would be 90-bit security, which is something that can be broken quite a few times per year by a billion dollars of hardware. A similar scale of ECC breaks by future quantum computers is enough to have proponents of solo-PQ claiming that ECC is useless, so how can they ignore a similarly impressive drop of lattice security and the risk of even larger future drops of lattice security?
This is where the stability argument sounds like it provides an answer: "Yeah, okay, cryptographers advocating lattice-based cryptography missed big attack speedups for many years, and in particular cryptographers in 2010 ignorantly thought LWE had 42% higher security levels than what cryptographers thought five years later, but this was a one-time screwup that we've solidly accounted for."
If you suppress the observation of how badly the community had botched this, in particular suppressing the 42% number, but preserve the effort to say that we're past this now, then you end up with NIST in 2022 writing "cannot be improved further", and with NIST's former lattice decision-maker claiming that security was "fully vetted" during the NIST competition, and with this new "stable for nearly a decade" quote.
But, in fact, the exponents of LWE attacks are continuing to drop. See, for example, the very small but still nonzero quantum improvement from a Eurocrypt 2023 paper, and the larger non-quantum improvement from my own paper later in 2023 on this topic, and an Asiacrypt 2025 paper experimentally confirming that the simplest version of my 2023 approach works as predicted, and yet another 2025 paper that's of particular interest for people worrying about the "exponential memory costs". It's simply not true that the attack exponents have been "stable for nearly a decade".