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

[Watson Ladd <[e-mail]>]

That's just objectively true.

In 2014 I exploited a number of TLS implementations, ranging from browsers
to embedded devices, exploiting incomplete formulas, failure to check y
etc. All these problems don't happen with X25519, which is why it rapidly
saw adoption.

On Thu, Oct 9, 2025, 8:03 PM Kampanakis, Panos <kpanos=
[e-mail]> 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 <[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]
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>