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

Hi DJB,

Sorry, let me try to be more constructive.

I really think that the way you’re communicating your concerns is simply impossible to digest by most of us.

You may have real concerns and real arguments, but the way you’re sending them is simply way too verbose and requires way too much time and effort for what many are at this point convinced is little payoff.

A lot of us are here on the IETF list as volunteers and otherwise lead very busy work lives with many obligations.

I would advise you, if you want people to read your arguments, to formulate them all into a single, self-contained paper in PDF format, in LNCS or some similar document style. Make such a paper at most 20 pages long, and make sure it’s self-contained, as succinct as possible, such that it’s the only thing anyone has to read to understand your arguments.

You can publish such a paper probably on ePrint, or if not, on your own website, or arxiv, or similar.

Your’e much more likely to have people make the effort to understand your full arguments this way, and furthermore, you’ll have a single authoritative source that people can cite, and you won’t have to keep rehashing your arguments 100 times everywhere.

The way you’re presenting your arguments now requires too much effort from volunteers who are exhausted from this debate, so I recommend you try the way I’m mentioning.

The above is written in good faith in an attempt to both help you express yourself more constructively and to also make the list function better. I hope you consider my advice.

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

> On 11 Aug 2026, at 5:53 PM, Nadim Kobeissi <[email protected]> wrote:
> 
> 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 <[email protected]> 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 -- [email protected]
>> To unsubscribe send an email to [email protected]
> 
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

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