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

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

> As for SecP256r1MLKEM768 and SecP384r1MLKEM1024 in this draft, the current status is that they're basically not supported in deployments at all.

acm.us-west-1.amazonaws.com (US),
secretsmanager.us-east-1.amazonaws.com (US), 
kms-fips.us-west-2.amazonaws.com  (US FIPS),
kms.eu-central-1.api.aws (Germany), 
kms.eu-west-2.amazonaws.com (UK), 
secretsmanager.ap-northeast-3.amazonaws.com (Japan),
acm.ap-southeast-2.api.aws (Australia) 
[ and many more ] 

Feel free to retract your statement as inaccurate and make another one. Maybe one to the effect that the sky is falling in year 2025 with SecP256r1MLKEM768 and SecP384r1MLKEM1024 because there was some new CVE recently or many implementation security issues a long time ago. Or something like that.

Reminder for the whole group: 
TLS is not just the web (origins, CDNs, and browsers). 




-----Original Message-----
From: D. J. Bernstein <[e-mail]> 
Sent: Monday, October 13, 2025 6:12 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.



Jan Schaumann writes:
> I don't think I can follow a logic that says
> X25519MLKEM768 should be recommended, but not the others (unless one 
> were to imply that standalone P-256 and P-384 should not be 
> recommended).

For me, the central point is that P-256 and P-384 create neverending real-world implementation failures, such as CVE-2023-6135 in Firefox.
This is an argument against standalone P-256 and P-384 as well as this draft's SecP256r1MLKEM768 and SecP384r1MLKEM1024.

For standalone P-256 in particular, the current status---mandated, and according to some reports still used by 10% of TLS sessions---means that the deprecation process should be gradual, starting with announcing the plan, mandating a replacement, tracking deployment trends, etc.

Standalone P-384 is easier to get rid of: it's not needed for getting data through, and it has far less usage in the first place.

As for SecP256r1MLKEM768 and SecP384r1MLKEM1024 in this draft, the current status is that they're basically not supported in deployments at all. The claims that these are needed for compliance don't seem to have withstood examination. So I'm puzzled as to why they're there.

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