[TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

["Kampanakis, Panos" <[e-mail]>]

P256 and P384 are risky choices now and the solution is for the draft to include only your curves with MLKEM768 or 1024? Come on man! 

-----Original Message-----
From: D. J. Bernstein <[e-mail]> 
Sent: Thursday, October 9, 2025 12:02 PM
To: [e-mail]
Subject: [EXTERNAL] [TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



It's good from a security perspective to see the increasing deployment of post-quantum cryptography. The most widely deployed option in this draft, namely X25519MLKEM768, is reportedly supported by ~40% of clients and ~30% of the top 100K servers, so presumably it covers ~10% of TLS traffic already, which is a big step above 0%.

Regarding the choice of ML-KEM, the _hope_ that ML-KEM will protect against quantum attacks shouldn't blind us to the _risk_ of ML-KEM being breakable. Many other post-quantum proposals have been publicly broken (see https://cr.yp.to/papers.html#qrcsp for a survey), including various proposals from experienced teams. Kyber/ML-KEM itself has seen quite a few vulnerabilities over the past 24 months, such as the following:

    * KyberSlash1 and KyberSlash2 (see https://kyberslash.cr.yp.to)
      prompted two rounds of security patches to the majority of ML-KEM
      implementations, including the reference code.

    * https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU
      prompted another round of ML-KEM security patches.

    * https://eprint.iacr.org/2024/080 showed that NIST's claims of many
      bits of extra ML-KEM security from memory-access costs---see
      https://web.archive.org/web/20231219201240/https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/faq/Kyber-512-FAQ.pdf
      ---are, asymptotically, completely wrong for 3-dimensional attack
      hardware and almost completely wrong for 2-dimensional attack
      hardware.

    * https://eprint.iacr.org/2024/739 showed that the same claims from
      NIST are, on real hardware, almost completely wrong. NIST has not
      withdrawn the claims but also has not disputed these papers.

    * https://link.springer.com/chapter/10.1007/978-3-032-01855-7_15
      debunked previous claims that "dual attacks" don't work, and
      concluded that none of the ML-KEM parameter sets reach their
      claimed security levels. A Kyber team member has disputed this
      conclusion, writing "there remains a few bits to be gained by
      cryptanalysts before the security levels would be convincingly
      crossed", but in any case this falls far short of the security
      margin that NIST was claiming just two years ago.

So it's good to see that the draft also meets the crucial requirement of having an ECC layer in every option. An ECC layer means that moving from today's X25519 (>80% of TLS) to X25519MLKEM768 definitely won't reduce security, even if ML-KEM collapses: i.e., we can comfortably _try_ to protect against quantum computers without risking a loss of security.

However, the following two concerns are serious enough that I can't support this draft in its current state.

First concern: The other two options in the draft make unnecessarily risky ECC choices, originally proposed by NSA in the 1990s. We've seen many ECC failures since then because of implementation screwups, and it's well understood (see https://cr.yp.to/papers.html#safecurves) how better ECC choices reduce these risks. For example, instead of using (x,y)-coordinates in ECDH and begging the implementor to check input validity (something we've seen going wrong again and again), we should be using x-coordinates on a twist-secure curve.

I understand that there are some earlier standards requiring risky ECC choices. I haven't seen a coherent argument that copying this flaw will noticeably improve deployability of the draft. Meanwhile this flaw is contrary to the "improve security" goal in the WG charter.

A sub-concern here is that, since MLKEM1024 is somewhat less risky than MLKEM768, it's reasonable for implementors to support MLKEM1024, but then the draft forces those implementors to use a poor ECC choice. This sub-concern is very easy to fix: add X25519MLKEM1024 and X448MLKEM1024.

Kicking the can down the road, saying that these options can be added by another spec later, would not address this sub-concern. An implementor looking for the lowest-risk post-quantum option in _this_ spec is forced into a poor ECC choice; _this_ spec should fix that.

Second concern: Kyber has always been in the middle of a patent minefield. The revisions to Kyber didn't do anything to move out of the minefield. ML-KEM, which is Kyber version 4, is in the same minefield.
NIST claims that its license agreements with two patent holders (Ding and GAM) allow free usage of unmodified ML-KEM under those patents; but there's another patent holder, Yunlei Zhao, who wrote in

    https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/F63mixuWBAAJ

that "Kyber is covered by our patents". I haven't heard reports of Zhao asking for money yet, but I also haven't seen a patent analysis explaining why Zhao is wrong.

What happens if a patent holder in, say, 2027 starts writing to one company after another saying "Here are records showing you've used ML-KEM, now pay $50000"? Probably a typical company pays the $50000 and promptly disables ML-KEM, regressing to the undesirable situation of users _definitely_ being unprotected against quantum attacks. Getting a patent-free replacement to the same level of deployment will take years.

The only way to provide interoperable post-quantum cryptography in this scenario is for a patent-free post-quantum option to be implemented and allowed everywhere, even if the patented option is default. Every spec should be taking responsibility for providing patent-free options. As above, kicking the can down the road does not address the problem; it means that the necessary job doesn't get done.

I'm not saying the WG should be trying to do patent analyses---on the contrary, IETF has a rule saying that it won't decide validity of any particular patent. I'm saying that the _claims_ from patent holders regarding ML-KEM warrant adding more options to mitigate patent risks.

---D. J. Bernstein


===== NOTICES REGARDING IETF =====

It has come to my attention that IETF LLC believes that anyone filing a comment, objection, or appeal is engaging in a copyright giveaway by default, for example allowing IETF LLC to feed that material into AI systems for manipulation. Specifically, IETF LLC views any such material as a "Contribution", and believes that WG chairs, IESG, and other IETF LLC agents are free to modify the material "unless explicitly disallowed in the notices contained in a Contribution (in the form specified by the Legend Instructions)". I am hereby explicitly disallowing such modifications. Regarding "form", my understanding is that "Legend Instructions" currently refers to the portion of

    https://web.archive.org/web/20250306221446/https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf

saying that the situation that "the Contributor does not wish to allow modifications nor to allow publication as an RFC" must be expressed in the following form: "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". That expression hereby applies to this message.

I'm fine with redistribution of copies of this message. There are no confidentiality restrictions on this message. The issue here is with modifications, not with dissemination.

For other people concerned about what IETF LLC is doing: Feel free to copy these notices into your own messages. If you're preparing text for an IETF standard, it's legitimate for IETF LLC to insist on being allowed to modify the text; but if you're just filing comments then there's no reason for this.

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