[TLS] Re: Last Call: <draft-ietf-tls-mlkem-09.txt> (ML-KEM Post-Quantum Key Agreement for TLS 1.3) to Informat ional RFC

In a TLS WG message, Paul Romer quantitatively estimated the dollar
benefit and dollar cost of replacing ECC+PQ with solo PQ, in particular
for the case of replacing X25519+ML-KEM with solo ML-KEM in the context
of TLS key exchange. He also solicited corrections to the calculations.

His estimates were that draft-ietf-tls-mlkem saves 2.9 nanodollars per
connection for a security cost of "at least" 270000 nanodollars per
connection. This makes draft-ietf-tls-mlkem look like a stunningly bad
idea---unless his numbers are off by five orders of magnitude.

I have some comments on the calculations. Cost-benefit analysis is
certainly relevant to IESG's "last call" regarding draft-ietf-tls-mlkem,
so I'm filing this as a reply to that.

To avoid a source of inaccuracies, I strictly avoid all use of LLMs in
writing all of my messages, including this one. 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.


1. Cost of keeping ECC

Structurally, the analysis that led to 2.9 nanodollars per connection is
missing a cost component, since it's looking at CPU time but not at
communication costs. I don't mean to suggest that it's important to
worry about every fringe cost (e.g., the cost of RAM for storing an
X25519 key), but the numbers below illustrate that communication costs
for X25519 can easily add 4 nanodollars per connection.

Counting communication costs can change close cryptographic comparisons,
including various comparisons that show up in the TLS context. We've
seen cases where failure to consider communication costs snowballed into
bad decisions. The difference isn't a big deal for the decision we're
talking about here between ECC+PQ and solo PQ, but the easiest way to
see that is to estimate the costs, so I'll do that below.

Paul Romer subsequently said that he had ignored communication cost
since that wasn't mentioned in the exchange he was commenting on. As
context, an opponent of solo PQ had written that ECC has "negligible
overhead"; the spec author had replied that "X25519 is almost twice as
slow as MLKEM768", citing a report on computation costs. But this focus
on a slice of the costs is error-prone.

Here's an example of estimating the total dollar costs of ECC per
connection including computation _and_ communication costs.

Readily available Dell servers---certainly not the state of the art in
high-performance computing, but easy to install and use---were already
carrying out 2^51 cycles of computation per dollar two years ago. See

    https://cr.yp.to/papers/pppqefs-20240327.pdf#time-cost

for details. At the same time Xfinity was charging $75/month for a 1Gbps
wired Internet plan allowing 1.2 terabytes/month, so about 2^34 bytes
per dollar:

    https://web.archive.org/web/20231210121119/https://www.forbes.com/home-improvement/internet/xfinity-internet-review/

Someone using these resources for an X25519 key exchange---generate and
send a new X25519 key, receive a response, calculate the resulting
shared secret---ends up spending

    * under 2^-34 dollars for under 2^17 CPU cycles with (e.g.) the
      formally verified X25519 code from s2n-bignum (see "X key" plus
      "X dh" in https://lib25519.cr.yp.to/speed.html) and

    * 2^-28 dollars for 2^6 bytes of communication (32-byte key, 32-byte
      ciphertext)

so total costs on that side are basically 2^-28 dollars, in other words
4 nanodollars, driven by communication costs.

Maybe the other side is incurring similar costs. Of course, scenarios
vary on both sides: for example, rented computer time is more expensive.
Concretely, Paul Romer said he was taking $0.10/hour as the cost of two
x86 threads rented from Amazon EC2. To convert this to dollars per
X25519 computation, I skimmed Amazon's purchase page to find $0.101/hour
for c6id.large with two 3.5GHz Intel Xeon 8375C Ice Lake "cores", which
presumably means threads. 2*3.5*10^9*3600/0.101 is 2^47.8 cycles per
dollar---or as low as 2^46.8 when the two threads compete for resources.
Either way, that's an order of magnitude below the 2^51 mentioned above
(for cores that have similar X25519 cycle counts).

Spending 2^17 CPU cycles per side, so 2^18 cycles total, on X25519
computations at 2^47 cycles/dollar would be spending 2^-29 dollars,
i.e., 2 nanodollars. Along with the networking costs mentioned above,
this would account for 6 nanodollars---or possibly as many as 10
nanodollars if both sides have those networking costs, but I'd expect
the average server side to have lower per-byte and per-cycle pricing,
so maybe 5 nanodollars is a reasonable overall estimate.

For comparison, the 2.9-nanodollar estimate of the X25519 cost comes
from Cloudflare's report of 19000 X25519 operations/second for an
unspecified CPU core. Maybe that's a slower core than 3.5GHz (as a data
point, my biggest CPUs run at 2.245GHz, with overclocking disabled), so
the difference between 2 and 2.9 isn't surprising. I'd guess that their
costs per CPU cycle are more like 2^-51 dollars than 2^-48 dollars, so
they'd end up far below 2 nanodollars. Anyway, networking costs would
again add 4 nanodollars for Xfinity, plus Cloudflare's network costs.

Looking at further variations in computation costs and communication
costs produces further variations in overall X25519 costs, sometimes
with computation costs being dominant and sometimes with communication
costs being dominant.

I should note that I'm focusing on current costs. There's of course a
long-term trend of technological improvements reducing computation costs
and communication costs (despite a recent bump in hardware prices from
an AI-driven supply shortage), with no clear end in sight.


2. Benefit of keeping ECC: scope analysis

Qualitatively, the usual argument that ECC+PQ is beneficial compared to
solo PQ is that ECC reduces the damage from PQ security failures. I'll
focus on that security benefit here; the problem is to quantify it.

The spec poses the wrong question about this: "Implementers must
evaluate their specific security, performance, and operational
constraints when deciding whether to deploy standalone ML-KEM or a
hybrid construction."

The reason I'm saying this delegation to implementors is wrong is that
it violates an IETF promise that

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

labels as "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."

It's particularly bad to push _security_ decisions downstream. How are
typical systems integrators supposed to evaluate the security risks of a
cryptosystem, beyond the extreme case of systems that have fast attack
demos online for everyone to try? People normally expect IETF's issuance
of an RFC to mean that IETF thinks the spec is safe to use; how often
will they even notice the spec saying they "must" reconsider this?

Anyway, IETF promises to "find the best solution for the whole
Internet". That isn't just about security. It's the opposite of telling
people to figure that out for themselves.

Paul Romer, taking the draft's "must evaluate" at face value, evaluated
his own situation: he reported that he's happy to pay "at least $10" per
year to keep the ECC seatbelt, and then he divided this by an estimate
of his number of key exchanges per year. But this limits the direct
scope of the analysis. Some people might say he isn't a representative
example of the general public. Maybe most people aren't willing to pay
as much as he is. Maybe most people do many more orders of magnitude
more key exchanges than he does, so many as to reverse the comparison.

The question we should instead be asking is the benefit to the _whole
Internet_ of continuing to require ECC (along with the PQ deployment
that happens), compared to the cost to the whole Internet of doing so.


3. Benefit of keeping ECC: probability analysis

I posted a paper in June with estimates of the number of ML-DSA keys
that will be broken purely because of exploitable implementation flaws,
and the extent to which ECC rescues security. The resulting figures---

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

---show roughly 1/8 chance of an ML-DSA key being broken in this way,
and ECC _almost_ always rescuing security in those cases.

For ML-KEM, the same methodology says roughly 1/16, accounting for
ML-KEM code being somewhat simpler and typically having had two years
more for flaws to be found. Of course, the actual number could be much
higher than 1/16 if the _spec_ is broken, but let's just run with the
1/16 number: if that's enough to show that solo ML-KEM is a terrible
idea then we don't need to consider the possibility of higher numbers.

There are other ways that TLS security might fail, but, unless those are
correlated with the ECC decision, removing ECC from ECC+ML-KEM exposes
roughly 1/16 of the TLS connections that would otherwise have been safe.


4. Benefit of keeping ECC: using TLS cost as a lower bound on TLS benefit

The whole point of TLS is to provide security ("TLS allows client/server
applications to communicate over the Internet in a way that is designed
to prevent eavesdropping, tampering, and message forgery").

We can estimate the benefit of this for the Internet, what people are
willing to pay for this security, as being _at least_ what people are
currently paying for it. There are many reasons to think that the
benefit is much more than this; I'll get back to that below.

In particular, the benefit to the Internet of TLS sessions that use
ECC+ML-KEM for key exchange is at least what people are paying for those
sessions. If removing ECC removes at least 1/16 of the benefit, by
destroying security for at least 1/16 of the connections, then it's
removing at least 1/16 of the TLS benefit, which is at least 1/16 of
what people are paying now.

This removal of security is irrational if the total cost of ECC is under
1/16 of the total cost of these TLS sessions. It's also irrational if,
e.g., the ECC/TLS cost ratio is below 1/4 and the TLS benefit is 4x the
TLS cost. It's also irrational if the TLS benefit is >16x the TLS cost,
no matter what the cost ratio is.

There's an interesting nonlinearity here because security is only as
strong as its weakest link. If people are willing to pay for a security
bundle then it's irrational to remove any necessary component of the
bundle; ergo, people are willing to pay that much for that component,
even though they might not be willing to pay that much separately _per_
component.


5. Benefit of keeping ECC: estimating TLS cost

The easy part of this is communication cost. Even at its lowest
bleeding-edge security level, ML-KEM uses 800 bytes for a public key
(X25519 adds 32 bytes) and 768 bytes for a ciphertext (X25519 adds 32
bytes). There are then many more bytes for other parts of TLS (e.g.,
certificates, protocol negotiation, per-packet overhead). I didn't try
to convince myself that every TLS session _has_ to be above 2^12 bytes,
but surely the average is above that without post-quantum signatures, so
X25519 is <1/2^6 of the communication cost.

Proponents respond by focusing on CPU cycles for X25519 and ML-KEM. As
https://blog.cr.yp.to/20260219-obaa.html#cost puts it: "People who look
up the cycle counts for, e.g., ML-KEM-768 on an AMD Zen 2 CPU core will
see, wow, only 44+43+45 kcycles for keygen+enc+dec, where the results
for lib25519 on the same core are larger, 26+74 kcycles on each side."

But (1) TLS spends many more CPU cycles on other operations; and (2) CPU
cycles are only one component of total TLS cost.

Regarding point #1, see, e.g.,

    https://web.archive.org/web/20260801133735/https://blog.cloudflare.com/how-expensive-is-crypto-anyway/

from 2017 where already 30.5% of the connections were using X25519,
accounting for only 4% of the BoringSSL CPU time. Scaling that up to
100% X25519 (reports in the last 2 years say 80-90%) would mean 13%.
Maybe it's higher because of total costs going down, maybe lower because
we're now including ML-KEM in the total, maybe lower because of X25519
speedups since then, but the point is that this fraction is much smaller
than the 2/3 that readers might expect upon hearing "X25519 is almost
twice as slow as MLKEM768".

I tried short connections using a simple OpenSSL client. They each used
2^26 CPU cycles. I'm sure this can be improved, but having <2^17 cycles
for X25519 turn into >1/16 of the total would mean <2^21 cycles per TLS
session. Signature computations by themselves are probably >2^20 cycles!

Regarding point #2, imagine that an average TLS connection manages to
get below 2^20 cycles, with X25519 using 1/8 of that. Remember that
X25519 uses <1/64 of the TLS bytes. The only way for X25519 to reach
1/16 of total TLS cost, considering both cycles and bytes, would be for
cycles to be above 40% of total TLS cost.

But remember my example of X25519 (on one side) using 2^-28 dollars for
2^6 bytes of Xfinity communication and under 2^-34 dollars for under
2^17 CPU cycles on a Dell server. The cycles here cost two orders of
magnitude less than the bytes do.

Pre-quantum signature systems have a similar ratio. ML-KEM and, if it's
used, ML-DSA have an even smaller ratio. If TLS authenticates and
encrypts a 1KB packet, it's incurring roughly 1000 cycles but also
sending a 16-byte MAC, again leading to an even smaller ratio.

Sometimes communication is less expensive. Maybe people can find some
corner cases where communication is so cheap and computation is so
expensive that _in those cases_ X25519 is over 1/16 of the total cost of
TLS. But focusing on corner cases is not finding "the best solution for
the whole Internet".

I see no basis for a claim by Dennis Jackson on list that the decision
between ECC+PQ and solo PQ is a "wicked problem" immune to resolution,
nor do I see an explanation from him of why this supposed wickedness
appears only for encryption, where he advocates multiple options, and
not for signatures, where he opposes multiple options.


6. Benefit of keeping ECC: estimating the total value of security

As mentioned above, there are many reasons to think that what people are
willing to pay for security is much more than what people are paying
today. But more work is needed to pin down numbers here.

For example, Michael Hayden, former head of NSA, former head of CIA,
said "We kill people based on metadata". One can try to figure out _how
many_ people the government kills based on metadata; how many fewer
people would be killed if there were better security for the metadata;
and similar statistics about other killers.

My understanding is that the non-killer parts of the government assess
each life as being worth $10 million, using Kip Viscusi's calculation.
Even if they think there's a discount for non-American lives, that's in
the ballpark of $1 trillion for the lives of the quarter million people
reportedly killed in conflicts last year. One can then try to figure out
what fraction of those would have been saved by better information
security: could this be 1%? 10%?

Meanwhile it seems much too narrow to view information security purely
through the lens of keeping people alive. I see from

    https://web.archive.org/web/20260616142126/https://www.forrester.com/blogs/global-cybersecurity-spending-to-exceed-300b-by-2029/

that cybersecurity _spending_ was already $150 billion in 2024. Here's a
reason to think that this has a great return on investment---that the
_value_ is much higher:

    https://www.forbes.com/sites/stevemorgan/2016/01/27/bank-of-americas-unlimited-cybersecurity-budget-sums-up-spending-plans-in-a-war-against-hackers/

said in 2016 that Bank of America had an "unlimited cybersecurity
budget". I think people (not just companies) would generally be happy to
pay more for better security, but simply don't know how they can do
better. Maybe some surveys could provide insight here.

One would then have to convert total information-security value into TLS
value by looking at the damage that a TLS failure does to security, and
then divide by the number of TLS sessions.

Again, I don't have numbers for this. I find it easier to simply look at
what people are paying per session as above; even though that's likely a
severe underestimate of the benefit, it's sufficient to make the case
for ECC+PQ rather than solo PQ. Figuring out the magnitude of the
underestimate would be important for this decision only if ECC were a
larger part of the cost of TLS.


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

The same language is used in, e.g., RFC 5831. The same language hereby
applies to this document. This is not disclaiming or limiting the
applicability of IETF policies; it is strictly following IETF policies.

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.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. The issue is instead with
modification, such as (1) IESG's May 2025 posting of an IESG-mangled
version of an appeal that I had filed and (2) IETF management selling
IETF mailing-list text to AI companies. This goes far beyond what
copyright law allows as fair use (such as giving quotes for purposes of
commentary). 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.

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]