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

[Nadim Kobeissi <[e-mail]>]

Dear DJB,

Your emails are too rare and too short.

Please make them longer and much more detailed. None of us have absolutely anything to do in our lives, so I strongly encourage you to fill the voids in all our hearts with enough material for us to ponder your arguments against the adoption of the ML-KEM draft, full-time, for the next fifty years (minimum).

Thank you for your service,

Nadim Kobeissi
Symbolic Software • https://symbolic.software

> On 11 Aug 2026, at 5:38 PM, D. J. Bernstein <[e-mail]> wrote:
> 
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]