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

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

Here is an idea: Write a “Deprecate ECDH with P256, P384 in IETF standards because they are insecure” draft like RFC9155<https://datatracker.ietf.org/doc/rfc9155/draft>.

Until then, let’s standardize the already assigned codepoints. More codepoints can come in separate drafts.


From: Watson Ladd <[e-mail]>
Sent: Friday, October 10, 2025 10:12 AM
To: Filippo Valsorda <[e-mail]>
Cc: Kampanakis, Panos <[e-mail]>; D. J. Bernstein <[e-mail]>; TLS List <[e-mail]>
Subject: RE: [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.


On Fri, Oct 10, 2025, 2:19 AM Filippo Valsorda <[e-mail]<mailto:[e-mail]>> wrote:
2025-10-10 06:29 GMT+02:00 Watson Ladd <[e-mail]<mailto:[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.

Do any of those attacks work against implementations that don't reuse ephemeral key shares (which thankfully are most of them now, to the point we've been discussing finally making it a MUST)?

Yes. For instance one of the vulnerabilities was a DoS due to a division algorithm that couldn't handle zero.

My understanding is that those attacks (and ~all the criteria in the "safecurves" webpage, last updated in 2017) are as irrelevant to authenticated ephemeral ECDH as the many cofactor attacks against Curve25519-based cryptosystems.

There's also  very poor performance of P384 and to a lesser degree P256.

(With apologies for indirectly taking the bait on suspicious CIA techniques<https://web.archive.org/web/20250726032250/http:/svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html>.)

On Thu, Oct 9, 2025, 8:03 PM Kampanakis, Panos <kpanos=[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Thursday, October 9, 2025 12:02 PM
To: [e-mail]<mailto:[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<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.