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 <[email protected]> Sent: Friday, October 10, 2025 10:12 AM To: Filippo Valsorda <[email protected]> Cc: Kampanakis, Panos <[email protected]>; D. J. Bernstein <[email protected]>; TLS List <[email protected]> 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 <[email protected]<mailto:[email protected]>> wrote: 2025-10-10 06:29 GMT+02:00 Watson Ladd <[email protected]<mailto:[email protected]>>: 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 <[email protected]<mailto:[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]<mailto:[email protected]>> Sent: Thursday, October 9, 2025 12:02 PM To: [email protected]<mailto:[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<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.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
