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

[Deirdre Connolly <[e-mail]>]

>
> 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.


Immediately after that message Yunlei declares "we hold all the patents
only for protection against credit (not for economic reasons)
<https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/fmBsJhLUBAAJ>"
and "we can make such an official claims about patents [allowing anybody
using it free use of our intellectual property, on condition that holders
of other patents involved in this standard will allow free use of theirs]
<https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/2NzgqoTaBAAJ>
"

On Thu, Oct 9, 2025 at 12:03 PM D. J. Bernstein <[e-mail]> wrote:

> 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]
>