This page presents quotes, with links for verification, of various talking points that have been showing up from proponents of solo PQ during the current limited-time voting-process on the IETF TLS mailing list. 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 now showing up are what proponents believe are their most convincing arguments.
Proponents lost the previous vote, but IETF rules are biased towards proponents: a successful WG vote is final while a failed WG vote is not. So proponents tried again, calling a new vote and flooding the room with positive votes. The last-minute talking points discourage opponents from speaking up. If proponents win this vote then they'll never have to address the objections to their claims. If it troubles you to see an engineering process replaced with a political process, you should speak up by 7 July 2026 in opposition to this document.
"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.
— "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.
— 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.
— "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.
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.
— 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.
"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 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 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. (That's Uri Blumenthal from "MIT Lincoln Labs", which, despite its university-associated name, is a fully owned subsidiary of the United States Department of War.)
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.
— 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.
— 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".