Hi Panos, I believe that X448 is the work of Mike Hamburg :-)
I would support X25519MLKEM1024 and X448MLKEM1024 as backup choices. On Fri, 10 Oct 2025 at 07:03, Kampanakis, Panos <[email protected]> wrote: > > 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 <[email protected]> > Sent: Thursday, October 9, 2025 12:02 PM > To: [email protected] > 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 -- [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]
