Thx Jan. One nuance: Cloudfront is Amazon's CDN, so we can call this web. Setting the web aside for a second.
There is a subset of AWS service endpoints where SecP256MLKEM768 (and X25519MLKEM768) has been deployed so far (100-200 in absolute numbers, they were reported in Jan's numbers as well). AWS has a total of a few thousands of those worldwide. These are TLS service endpoints that do not fall in the web umbrella. And they generally see vast numbers of aggregate connections per day. Browsers (over the AWS Console) are just a subset of the clients that connect to them. Other clients include applications built on top of SDKs. There is great diversity of clients, programming languages, SDKs (Java, Go, Rust, Python, C etc) and customer-built applications. We simply can't control if a certain application+SDK integrates with OpenSSL 3.5+ and a customer will want to enable certain groups over others or even if the application will integrate with a library that does not support exactly the one group we want. That is why I keep saying that web players have been sharing connection data and that is very useful, but it does not mean that all TLS connections on the Internet come from a browser or web-based application destined to a CDN/web server. We have the three codepoints already, let's standardize them. X25519MLKEM768 can be the RECOMMENDED=Y, that is probably for the best. -----Original Message----- From: Jan Schaumann <[email protected]> Sent: Tuesday, October 14, 2025 5:29 PM To: [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. Eric Rescorla <[email protected]> wrote: > On Tue, Oct 14, 2025 at 1:13 PM Jan Schaumann <jschauma= > [email protected]> wrote: > > https://www.netmeister.org/blog/pqc-use-2025-09.html > Note that the vast majority of the sample set (and hence the > X25519MLKEM768 > support) is Cloudflare, so to some extent we're seeing the decision by > Amazon to support P-256 and Cloudflare not to. Correct. Which, in turn, is rather likely influenced by the fact that none of the major browsers currently implement a hybrid PQ/T kex other than X25519MLKEM768. So yeah, it's a small number of big players that are reinforcing each others' decisions here. -Jan _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
