This is the fourth in a series of four messages responding to IESG's
"last call" for draft-ietf-tls-mlkem.

This message quotes and replies to various statements posted on the TLS
list by proponents of draft-ietf-tls-mlkem during WGLC.

This is within TLS WG scope as per RFC 2418 stating that disagreements
"must be resolved by a process of open review and discussion", a rule
that does not disappear when chairs fraudulently claim consensus. The
newer IESG "last call" on draft-ietf-tls-mlkem, the "last call" that I'm
replying to here, was triggered by the same false claim.

I posted these replies online during and shortly after WGLC, but the TLS
WG chairs were censoring the mailing list at that point. I've slightly
edited this compared to what I posted before. I haven't included any
references to the last few weeks of claims regarding PQ cryptanalysis;
none of my comments rely in any way on whether any of those claims turn
out to be correct.

As noted earlier in this series, I plan to file a complaint with the
chairs under RFC 2026, Section 6.5, regarding their consensus claims;
but my understanding is that the RFC 2026 procedures require a "detailed
and specific description of the facts of the dispute". I'm not done
collecting that description yet, and won't be done before the end of
IESG's limited-time "last call". I do not want to miss this opportunity
to inform IESG of how weak the case for this document is.

I also have a chart https://blog.cr.yp.to/20260221-structure.html, most
recently updated around the beginning of the WGLC (late June 2026), of
arguments and counterarguments. My impression is that what proponents
posted during WGLC is what they consider their strongest arguments, and
those are what I'm addressing below. I'm skipping off-topic arguments
from proponents, such as ad-hominem attacks; my goal here is to address
things that _sound_ like they're actually addressing the _content_ of
the proposal on the table.

To avoid a source of inaccuracies, I strictly avoid all use of LLMs in
writing all of my messages, including these four messages. See

    https://www.nytimes.com/2026/04/13/well/ai-chatbots-cancer.html?unlocked_article_code=1.4FA.nfHn.tMfHDs5AvOKj&smid=url-share

for motivation. I request that responses also avoid all use of LLMs.


## Strawman arguments

"Blumenthal, Uri - 0553 - MITLL" writes:
> 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.

Richard Barnes writes:
> What if ECDH implementations have bugs?

Same strawman.


## Mismanaging risks

"Blumenthal, Uri - 0553 - MITLL" writes:
> Do we trust ML-KEM? If yes, adding ECC is an unnecessary complexity.
> If no, we shouldn't be using it at all --- hybrid or otherwise.

"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 throwing ECC away.

"Scott Fluhrer (sfluhrer)" writes:
> However, if you don't trust that ML-KEM is secure, then you can't
> trust that draft-ietf-tls-ecdhe-mlkem is postquantum secure.  That
> sounds like you would be recommending people to use something that you
> don't believe meets the security goal, and would be, in fact, insecure
> after Q-day.

Same risk-management error.

"Scott Fluhrer (sfluhrer)" writes:
> I've said this before; I'll say it again - if you don't believe that
> pure ML-KEM gives sufficient security, then (by the same logic) you
> have to believe that hybrid doesn't give sufficient postquantum
> security.

Same risk-management error once again.

"Blumenthal, Uri - 0553 - MITLL" writes:
> Well, if Dr. Avanzi isn't confident enough in his design, what can I
> say, except that perhaps he should've worked harder back then?

This was in response to Roberto Avanzi, one of the Kyber/ML-KEM
designers---

    https://web.archive.org/web/20190214071008/https://pq-crystals.org/kyber/data/kyber-specification.pdf

---posting the following in a discussion elsewhere: "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." Source:

    https://web.archive.org/web/20260710230832/https://www.linkedin.com/posts/billatnapier_the-debate-around-hybrid-key-exchange-ecdh-activity-7480546081622196225-aldO

Mr. Blumenthal's "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.

Ilari Liusvaara writes:
> The candidates to NISTPQC were very diverse, and as different types of
> cryptography tend to have different attacks (with some common ones),
> one can not use failures of other types (e.g., SIKE) or the general
> failure rate (there was plenty of 'snake oil') as evidence against
> Kyber/ML-KEM. For the submissions based on lattices, the issues seemed
> to be mostly bad parameter choices and some other details. Which is
> also to be expected, and does not reflect badly on Kyber/ML-KEM.

36% of the submissions selected by NIST in 2019 for the second round
were broken by 2023:

    https://cr.yp.to/papers/qrcsp-20231202.pdf

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 (https://cr.yp.to/papers.html#hila5) and Round2
(https://eprint.iacr.org/2020/241) The remaining lattice candidates
lost many bits of security and continue to lose security. For example:

    https://eprint.iacr.org/2025/1910
    https://eprint.iacr.org/2026/279

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.

Ilari Liusvaara writes:
> Cryptography based on lattices is not new. NTRU is from 1996, and LWE
> (which is commonly regarded as better than NTRU) is from 2005.

RC4 is not new. It was published in the 1990s, and its security is the
topic of nearly 100 attack papers:

    https://ntruprime.cr.yp.to/latticerisks-20211031.pdf#page.6

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:

    https://cr.yp.to/papers.html#rc4biases

Similarly, various lattice-based cryptosystems were introduced in the
1970s as "knapsack" systems and were broken:

    https://www-users.cse.umn.edu/~odlyzko/doc/arch/knapsack.attacks.pdf

The first versions of NTRU in the 1990s were broken:

    https://www.di.ens.fr/david.pointcheval/Documents/Papers/2003_crypto.pdf

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 2^150
operations" to break:

    https://web.archive.org/web/20111206143256/https://eprint.iacr.org/2010/613.pdf

After many attack improvements, the latest academic attack demos are
already beyond dimension 200:

    https://www.latticechallenge.org/svp-challenge/

During the NIST competition, Kyber was a moving target. For example,
Kyber-2019 eliminated the Kyber-2017 key compression---

    https://web.archive.org/web/20191017000831/https://pq-crystals.org/kyber/data/kyber-specification-round2.pdf

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

    https://web.archive.org/web/20230310174959if_/https://pq-crystals.org/kyber/data/kyber-specification-round3-20210804.pdf

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.

Ilari Liusvaara writes:
> In addition Kyber/ML-KEM also has extensive analysis as part of
> NISTPQC, probably exceeding any other candidate KEM.

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" (https://eprint.iacr.org/2018/079)
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" (https://eprint.iacr.org/2018/1089) were somewhat
more specific---"decryption failures" are an attack avenue that had been
eliminated by some lattice submissions---but still broader than Kyber.

"Blumenthal, Uri - 0553 - MITLL" writes:
> If your data will remain sensitive - then the difference between "it
> got compromised today" and "it got compromised with CRQC" is small,
> and ECC won't help at all.

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. See

    https://cr.yp.to/papers/mldsa-20260601.pdf#timeline
    https://cr.yp.to/papers/mldsa-20260601.pdf#shor

for more information on these three points.

Rob Hunter writes:
> There might well be an argument to be made that post Q date, hybrids
> don't offer redundancy in the implementation if a security function
> fails.

Same mistake as previous quote ("won't help at all").

Daniel Apon writes:
> In 2017, Daniel J. Bernstein made a bet for US$2,048 ... that quantum
> computers will publicly break the RSA-2048 factoring challenge no
> later than 2033.
  [ ... ]
> My position is that ECC will be broken "soon"

Same issue as the previous two quotes.

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_.

I stated A. The reader understands "will be broken 'soon'" as something
like C. Arguing that ECC has no value in ECC+PQ requires D.

Soatok Dreamseeker writes:
> If the NSA thought they had a NOBUS backdoor in ML-KEM, why would they
> be moving everything to use it for TOP SECRET classified information
> as fast as they can? That would be malfeasance on a level that is
> beyond parody.

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. (See
https://cr.yp.to/papers.html#dual-ec for background.)

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:

    https://web.archive.org/web/20260405204054/mailarchive.ietf.org/arch/msg/tls/Sms0nHOa2oCEI-cx0kqQJaSEe5M/

Second, the NSA director publicly claimed in 1979---

    https://web.archive.org/web/20220805195031/https://cryptome.org/nsa-inman-1979.pdf

---that NSA had "endorsed the use of DES for the encryption of national
security-related information, including selected classified
information". But secret NSA documents

    https://archive.org/details/cold_war_iii-nsa/cold_war_iii-ISCAP/page/n239/mode/2up

showed that NSA knew that DES was "weak enough" to break. DES was in
fact remarkably cheap to break even with 1970s technology:

    https://ee.stanford.edu/~hellman/publications/36.pdf

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:
https://blog.cr.yp.to/20251004-weakened.html#dogfood

John Mattsson writes:
> Standalone ML-KEM is not replacing X25519MLKEM768. Where do the
> repeated and incorrect claims about 'replacing,' 'removing,' or
> 'weakening' originate from?

I've been consistently recommending ECC+PQ since 2016:

    https://cr.yp.to/talks.html#2016.02.24

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. As

    https://blog.cr.yp.to/20260702-standard.html

explains, 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---

    https://blog.cr.yp.to/20251004-weakened.html#tls

---isn't going to suddenly stop with issuance of an RFC; it will
continue into pressuring companies to switch to solo PQ. See

    https://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220/

for a news story about an earlier incident of NSA pressuring industry to
switch to an option that NSA had convinced SDOs to include.

"Blumenthal, Uri - 0553 - MITLL" writes:
> The integration logic between ML-KEM and ECC creates additional
> complexity where subtle bugs can undermine the security of both
> components.

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

    https://cr.yp.to/papers.html#pqcomplexity

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.

Peter C writes:
> Client-side ephemeral key generation already mitigates many potential
> ML-KEM implementation vulnerabilities. Take the faulty re-encryption
> check in CVE-2026-6330 as an example. Exploiting this would require
> the client to initiate hundreds of TLS connections with an
> attacker-controlled server using the same key pair, where a
> significant proportion of those connections fail giving a
> decrypt_error. It doesn't seem plausible to me that this could happen
> without being noticed and immediately fixed.

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"---

    https://web.archive.org/web/20260511083730/https://words.filippo.io/crqc-timeline/

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

    https://arxiv.org/abs/2107.04940

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

Aaron Gable writes:
> objections have been raised, addressed, and yet continue to be raised.
> The core objection is that this document appears to endorse a protocol
> which some members of this WG consider less secure than other
> available protocols. This objection has been addressed: the document
> explicitly does not recommend the use of pure ML-KEM, it merely
> standardizes it for interoperability

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.


## Random errors

"Blumenthal, Uri - 0553 - MITLL" writes:
  [ ECC+PQ ]
> doubles the FIPS/compliance validation effort and timeline.

False. NIST SP 800-227---

    https://web.archive.org/web/20250924170028/https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-227.pdf

---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: https://blog.cr.yp.to/20260219-obaa.html#recap

Let me spell out how this is connected to FIPS compliance. 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":

    https://web.archive.org/web/20260701150831/https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf

For key establishment, FIPS 140-3 approves whatever is approved in NIST SP
800-140D:

    https://web.archive.org/web/20260513213203/https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr2.pdf

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. As

    https://web.archive.org/web/20251201005927/https://csrc.nist.gov/projects/cmvp/sp800-140d

shows, that page redirects to

    https://csrc.nist.gov/projects/cryptographic-module-validation-program/sp-800-140-series-supplemental-information/sp800-140d

which as shown in

    https://web.archive.org/web/20260709000607/https://csrc.nist.gov/projects/cryptographic-module-validation-program/sp-800-140-series-supplemental-information/sp800-140d

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

"Blumenthal, Uri - 0553 - MITLL" writes:
> Hybrid systems require maintaining parallel PKI infrastructures---both
> classical and PQ certificate chains.

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: https://blog.cr.yp.to/20260221-structure.html#encapsulated

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.


## False claims of inconsistencies

Richard Barnes writes:
> We need defense in depth! -- Why is this the one time in history that
> this is the case?  We didn't do RSA-ECC hybrids during that
> transition.

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

    https://web.archive.org/web/20240414055749/https://shaih.github.io/pubs/mars/mars.pdf

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

    https://web.archive.org/web/20070628104530/https://www.cosic.esat.kuleuven.be/nessie/deliverables/decision-final.pdf

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:

    https://web.archive.org/web/20130526024113/http://googleonlinesecurity.blogspot.com/

Software was often limited to 1024 bits for DH:

    https://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

Uri Blumenthal wrote on the TLS mailing list that he would "vote against
anything (ephemeral DH-related :) larger than 1536 bits":

    https://web.archive.org/web/20200807013329/https://mailarchive.ietf.org/arch/msg/tls/yPFMTrRwCc8R4AoHzDPZstyGiCY/

The situation today is different. ECC+PQ has only negligible cost beyond
solo PQ:

    https://blog.cr.yp.to/20260219-obaa.html#cost

This hasn't stopped proponents of solo PQ from insinuating that ECC+PQ
is too expensive (see "Hybrid systems require additional computational
resources" etc. from Mr. Blumenthal quoted below), but this time the
numbers don't back them up.

"Markku-Juhani O. Saarinen" writes:
> As a sidenote, we already have the Chinese TLS 1.3 Cipher Suites (RFC
> 8998), Russian TLS 1.2 Cipher Suites (RFC 9189), etc., and a lot more
> obscure and weird ones too. Those didn't generate nearly as much
> discussion and passion as this seems to have.

No IETF WG ever approved those documents!

IETF has an "ISE" mechanism to produce RFCs without WG review, 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".

Paul Wouters writes:
> The people who claim that pure MLKEM does not need an RFC seem to
> overlap strongly with those who said the SSH NTRUprime+X25519 hybrid,
> despite being massively deployed, still absolutely needed an RFC
> number. It seems this argument is not used objectively in IETF
> discussions, but more as stand-in argument to get one's own
> preferences codified.

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

    https://datatracker.ietf.org/doc/rfc9941/

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.


## Hyping the costs of ECC

"Blumenthal, Uri - 0553 - MITLL" writes:
> Hybrid systems require additional computational resources, memory, and
> bandwidth"; "this overhead may matter"; "Large multi-user servers may
> not appreciate this overhead because it reduces the number of
> connections per unit of time, that in turn reduces their revenue";
> "further increases code size, RAM usage and storage requirements";
> "FPGA implementations may not be able to tolerate this"; "this
> combined footprint may exceed available resources"; "might be unable
> to accommodate the hybrid approach"; "creates deployment barriers and
> may force continued use of classical-only crypto in resource-limited
> environments

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:

    https://blog.cr.yp.to/20260219-obaa.html#cost

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. See

    https://blog.cr.yp.to/20260221-structure.html#cost

for examples of these insinunations.


## Arguing that NSA should get whatever it pays for

Antony Vennard writes:
> As a result of CNSA 2.0 preferring pure-PQ, a number of major
> libraries have already implemented either all code points or some of
> them

IETF says in

    https://web.archive.org/web/20250528213926/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/

that 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.


## Confusing this proposal with a different proposal

Paul Wouters writes:
> Also, if you think mlkem is unsafe as PQ algorithm, which alternative
> would you propose? How would we reach consensus without rerunning a
> NISTlike algorithm competition. And run it quickly to defend against
> 'store now, decrypt later' ?

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.

"Blumenthal, Uri - 0553 - MITLL" writes:
> Maintaining implementations of two separate cryptographic algorithms
> increases technical debt (for no good reason)

The TLS standard https://datatracker.ietf.org/doc/html/rfc8446 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: see

    https://web.archive.org/web/20260721034557/https://mailarchive.ietf.org/arch/msg/tls/ZjLopKjHGn-kJUfdBZNVWcZE8AQ/

where Mr. Blumenthal writes "Hybrid and Pure have different risk
profiles and trade-offs. It makes sense to let the user pick what suits
best." How can Mr. Blumenthal credit this proposal with skipping ECC
maintenance, when that's simply not what this proposal does?

Note that there are other inconsistencies in the case for solo PQ:

    https://blog.cr.yp.to/20260221-structure.html

Including the purported rationale _in the spec_ would force that
rationale to reach consensus. Instead the spec omits its rationale,
freeing up proponents to issue contradictory ad-hoc arguments.

Rob Hunter writes:
> It is not unreasonable to argue that a smaller code base is easier to
> evaluate (non hybrid).

Same confusion as previous "increases technical debt" quote. TLS already
mandates ECC; the proposal for IETF to allow solo PQ is _not_ a proposal
to remove ECC from the TLS code base.

"Markku-Juhani O. Saarinen" writes:
> With hybrid, one is significantly increasing the size and complexity
> of a hardware implementation

No, this is the same confusion as above.

Antony Vennard writes:
> I think that having tls-wg have oversight of the specification is
> better than not, given implementation will likely happen.

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

    https://web.archive.org/web/20260808194952/https://mailarchive.ietf.org/arch/msg/tls/jLOlNwL-0XxkJ0prqSoXSzim1wQ/

But issuing warnings as a separate document such as

    https://datatracker.ietf.org/doc/html/rfc7465

is much better than burying warnings inside a document that readers will
typically understand as endorsement. As

    https://web.archive.org/web/20260416085627/https://mailarchive.ietf.org/arch/msg/tls/LqG-gHxgRvVPebE3m28D8VT7dN4/

shows, this has been pointed out before.

Rob Hunter writes:
> If other countries wish to adopt non-hybrids that is their own policy
> decision and I respect their right to make such decisions.

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 promises to its funding
sources:

    https://web.archive.org/web/20260622091826/https://www.ietf.org/support-us/endowment/

Specifically, IETF says that it 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".


## Denying PQ risks

Soatok Dreamseeker writes:
> SIKE being broken was the international standardization effort
> successfully working to motivate folks to find attacks against novel
> cryptosystems. Using it as an indictment of an unrelated algorithm is
> alarmingly ignorant.

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 2^64":

    http://web.archive.org/web/20230521200038/https://csrc.nist.gov/csrc/media/publications/fips/186/2/archive/2001-10-05/documents/fips186-2-change1.pdf

OCB2 was published in 2004, was standardized in 2009, and was suddenly
shown in 2018 to be efficiently breakable:

    https://eprint.iacr.org/2018/1040

XCB was published in 2007, was standardized in 2010, and was suddenly
shown in 2024 to be efficiently breakable:

    https://eprint.iacr.org/2024/1554

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 such as

    https://web.archive.org/web/20260630121205/https://mailarchive.ietf.org/arch/msg/tls/nVeE4qhVAnLCOfGZcNloENNF34Q/

that Kyber/ML-KEM was "fully vetted" during the NIST competition are
contradicted by, e.g., papers in October 2025, December 2025, and
February 2026:

    https://eprint.iacr.org/2025/1910
    https://eprint.iacr.org/2025/2189
    https://eprint.iacr.org/2026/279

Each of these papers claims 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.

Soatok Dreamseeker writes:
> 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:

    https://kyberslash.cr.yp.to/libraries.html

Looking at this history, and at the broader history of hundreds of
vulnerabilities in cryptographic libraries (see generally
https://arxiv.org/abs/2107.04940) 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.


## Pseudoscience

Antony Vennard writes:
> I do not believe the risk of ML-KEM (and ML-DSA) to be severe: there
> is no known cryptanalysis currently exploiting rank >=2 module
> structure at these parameters that performs better than generic
> lattice reduction. Module-LWE also has a (granted, an asymptotic)
> worst-case-to-average-case reduction - something neither RSA nor ECDLP
> had.

My 30 June 2026 blog post

    https://blog.cr.yp.to/20260630-risk.html

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:

    https://blog.cr.yp.to/20260630-risk.html#worst

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.

mark@schultz-wu.com writes:
> SOTA attacks against LWE (and its algebraically structured variants)
> have been "stable" in the sense that they take 2^{cn} time for a
> constant c (and have exponential memory costs as well iirc) for close
> to 2 decades. Over time the constant c has mildly decreased, but it
> has now been stable for nearly a decade.

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 I'm quoting 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).
See https://eprint.iacr.org/2015/1128 for the 0.292 number and for
references explaining the earlier numbers.

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---see

    https://cr.yp.to/papers/mldsa-20260601.pdf#shor

---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"---

    https://web.archive.org/web/20221005222322/https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413-upd1.pdf

---and with NIST's former lattice decision-maker claiming that security
was "fully vetted" during the NIST competition---

    https://web.archive.org/web/20260630121205/https://mailarchive.ietf.org/arch/msg/tls/nVeE4qhVAnLCOfGZcNloENNF34Q/

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

    https://arxiv.org/abs/2205.14023
    https://cr.yp.to/papers.html#hybrid
    https://eprint.iacr.org/2025/1910
    https://eprint.iacr.org/2025/2189

It's simply not true that the attack exponents have been "stable for
nearly a decade".


---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "This document may not be
modified, and derivative works of it may not be created, and it may not
be published except as an Internet-Draft."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

That language hereby applies to this document. This is not disclaiming
or limiting the applicability of IETF policies; it is strictly following
IETF policies. IETF has similarly published, e.g., RFC 7425, which says
the following: "This document may not be modified, and derivative works
of it may not be created, except to format it for publication as an RFC
or to translate it into languages other than English."

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

IETF Executive Director Jay Daley says that informative text can
"contextualise and disambiguate normative text as it does here". When he
was asked what he claimed was ambiguous about the BCP 78 "explicitly
disallowed" provision, he did not reply. There is no ambiguity, and an
"Exposition of Why These Procedures Are the Way They Are" is not a
change to the procedures.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. However, BCP 78's default
position, without the opt-out, is a power grab that goes far beyond
redistribution and far beyond what copyright law allows as fair use
(such as giving quotes for purposes of commentary). BCP 78 authorizes
arbitrary modifications, such as plagiarism, quote falsification, data
falsification, and IETF management selling IETF mailing-list text in
bulk to AI companies spreading further misinformation.

For example, Google, a major source of IETF funds, systematically
ingests IETF mailing-list text into its AI system, which modifies the
text and frequently spits out misinformation to readers. IETF is only
one of many terms-of-service battlegrounds; this is not a reason to skip
the battle.

IETF itself also carries out problematic modifications. For example, in
May 2025, IESG posted an IESG-mangled version of an appeal that I had
filed, and then in its response confused exactly the point obfuscated by
that mangling. When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management had the power to do whatever it wanted.