There is a reason why people choose slower MLKEM1024 (and slower SecP384r1)
over faster MLKEM768. It would be good to keep that in mind.
--
V/R,
Uri
There are two ways to design a system. One is to make it so simple there are
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare
From: John Mattsson <[email protected]>
Date: Sunday, October 12, 2025 at 11:53
To: Kampanakis, Panos <[email protected]>, D. J. Bernstein
<[email protected]>, [email protected] <[email protected]>
Subject: [EXT] [TLS] Re: Working Group Last Call for Post-quantum Hybrid
ECDHE-MLKEM Key Agreement for TLSv1.3
>P256 and P384 are risky choices now and the solution is for the draft to
>include only your curves with MLKEM768 or 1024? Anything that can go wrong,
>will go wrong. History is full of libraries with no built‑in point validation,
>libraries
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
>P256 and P384 are risky choices now and the solution is for the draft to
>include only your curves with MLKEM768 or 1024?
Anything that can go wrong, will go wrong. History is full of libraries with no
built‑in point validation, libraries that perform point validation incorrectly,
or libraries that leave point validation entirely to the user. While P-256 and
P-384 can be used correctly, many implementations violate NIST’s requirement
for point validation. The risk increases further because many implementations
also violate NIST’s requirement to not reuse ephemeral keys, which breaks
session‑key independence. I don't think Ed448 can be described as a Bernstein's
curve.
I think the draft should discuss the performance differences. This is likely
very important for readers of the document. For optimized implementations,
X25519MLKEM768 is significantly faster than SecP256r1MLKEM768 which is
significantly faster than SecP384r1MLKEM1024. And as optimized ML-KEM is
significantly faster than X25519, they are all significantly slower than
standalone ML-KEM.
https://blog.cloudflare.com/es-es/pq-2024/
Performance is practically an extremely important security factor as slow
performance often lead to violated requirements.
Cheers,
John
===== NOTICES REGARDING CONTRIBUTIONS =====
It has come to my attention that some people want to limit the freedom to use
information in IETF contributions. I am hereby explicitly dedicating my message
above to the public domain.
From: Kampanakis, Panos <[email protected]>
Date: Friday, 10 October 2025 at 05:03
To: D. J. Bernstein <[email protected]>, [email protected] <[email protected]>
Subject: [TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM
Key Agreement for TLSv1.3
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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2Fpapers.html%23qrcsp&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8cad2bc84b1a46fe716208de07a9889c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638956621989450879%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dToYMJzMW0WfzImt77QE3GJYIRPKOQ675B8zWASijZk%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkyberslash.cr.yp.to%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8cad2bc84b1a46fe716208de07a9889c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638956621989483370%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gxnx2kWM3sYrC78tIlZE4UV5IHfJ99t0Oa9swxvh5ok%3D&reserved=0)<https://kyberslash.cr.yp.to/>
prompted two rounds of security patches to the majority of ML-KEM
implementations, including the reference code.
*
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fg%2Fpqc-forum%2Fc%2FhqbtIGFKIpU&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8cad2bc84b1a46fe716208de07a9889c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638956621989503997%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=O6EiBy%2Fux3dGs%2BVnjGcxn2iqXefSjA7HIWDGXA0pic8%3D&reserved=0<https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU>
prompted another round of ML-KEM security patches.
*
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2024%2F080&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8cad2bc84b1a46fe716208de07a9889c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638956621989524597%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OfDcfsZr3r63YVcwlnz0y50WNjsZY8J7exgekKSDGe4%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20231219201240%2Fhttps%3A%2F%2Fcsrc.nist.gov%2Fcsrc%2Fmedia%2FProjects%2Fpost-quantum-cryptography%2Fdocuments%2Ffaq%2FKyber-512-FAQ.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8cad2bc84b1a46fe716208de07a9889c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638956621989545230%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q0dlw3uYAWCFefNTPHQOF40ZHW6ODu0cfUuC%2FW3FCKA%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2024%2F739&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8cad2bc84b1a46fe716208de07a9889c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638956621989565097%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jE7OgJ547dKdS9QdqEAGwjjYo8E6ovc0p47EJUJtk7E%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flink.springer.com%2Fchapter%2F10.1007%2F978-3-032-01855-7_15&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8cad2bc84b1a46fe716208de07a9889c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638956621989583408%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mPpTv%2Fua7quTM4jiQ%2BoL5CWEXsPElqokHqHDEX4uejM%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2Fpapers.html%23safecurves&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8cad2bc84b1a46fe716208de07a9889c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638956621989599880%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PAvZ4crazKRRfKUCcqn9SJs187WRPf89Y0cNgrLP86o%3D&reserved=0)<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fg%2Fpqc-forum%2Fc%2FFm4cDfsx65s%2Fm%2FF63mixuWBAAJ&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8cad2bc84b1a46fe716208de07a9889c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638956621989619589%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6rhAtiP0BEZEWXZQaeg%2FxEsiWzFF4oMVHkh5SfT5io4%3D&reserved=0<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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20250306221446%2Fhttps%3A%2F%2Ftrustee.ietf.org%2Fwp-content%2Fuploads%2FCorrected-TLP-5.0-legal-provsions.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8cad2bc84b1a46fe716208de07a9889c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638956621989639895%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cfrhwGSukIJrWCc%2FVnH%2FJscSm1xcPETMdvHoiOEGwco%3D&reserved=0<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]
