This is the breakdown of client support Cloudflare sees (relative to any PQ support) in the last 24 hours by handshakes:
94% X25519MLKEM768 8.1% X25519Kyber768 0.038% MLKEM768 0.014% CECPQ2 0.012% MLKEM1024 0.002% SecP384MLKEM1024 0.002% SecP256MLKEM768 0.00005% MLKEM512 0.0000003% SecP256Kyber768 If we ignore the CECPQ2 and Kyber hybrids, then X25519MLKEM768 is supported by 99.992% of clients that offer PQ. Again ignoring CECPQ2 and Kyber, we see the following shares sent in the ClientHello. 99.96% [X25519MLKEM768] 0.02% [X25519MLKEM768, MLKEM768] 0.007% [MLKEM768, MLKEM1024] 0.005% [X25519MLKEM768, MLKEM768, MLKEM1024] 0.002% [X25519MLKEM768, SecP256MLKEM768, SecP384MLKEM1024] (...) 0.00001% [MLKEM512, MLKEM768, MLKEM1024] (...) 0.0000003% [SecP256MLKEM768, SecP384MLKEM768] (X25519MLKEM768 is in all the unlisted ClientHello's) It is wise to keep the set of recommended algorithms as small as possible as there is a real cost to fragmentation. We welcome draft-ietf-tls-key-share-prediction which offsets the performance impact of the HelloRetryRequest if we do get worse fragmentation, but not every client will be able to use it and not every server will be able to provision the DNS records. I can see an argument for Recommended=Y for both X25519MLKEM768 and SecP384MLKEM1024, but I do not see any value in recommending both X25519MLKEM768 and SecP256MLKEM768. At the moment we only support X25519MLKEM768 and X25519Kyber768, and have no immediate plans to change that except for disabling X25519Kyber768 at some point. Best, Bas On Tue, Oct 7, 2025 at 4:52 PM Eric Rescorla <[email protected]> wrote: > I have reviewed this document and I think it is ready to go with > one exception, namely the Recommended column. > > The RFC 8447 standard for "Recommended=Y" is: > > Per this document, a "Recommended" column has been added to many of > the TLS registries to indicate parameters that are generally > recommended for implementations to support. > > I think there's a general expectation that we want people to > implement and deploy these algorithms, and I would expect > that the X25519 and P-256 versions to be widely deployed, > at least on the Web. Therefore, I think we should mark all of > these as Recommended=Y. I note that this would require > advancing this document as Proposed Standard. We should do > that as well. > > -Ekr > > > > > On Tue, Oct 7, 2025 at 6:47 AM Joseph Salowey <[email protected]> wrote: > >> This is the working group last call for Post-quantum hybrid ECDHE-MLKEM >> Key Agreement for TLSv1.3. Please review draft-ietf-tls-ecdhe-mlkem [1] and >> reply to this thread indicating if you think it is ready for publication or >> not. If you do not think it is ready please indicate why. This call will >> end on October 22, 2025. >> >> Please note that during the WG adoption call, Dan Bernstein pointed out >> some potential IPR (see [2]), but no IPR disclosure has been made in >> accordance with BCP 79. Additional information is provided here; see [3]. >> >> BCP 79 makes this important point: >> >> (b) The IETF, following normal processes, can decide to use >> technology for which IPR disclosures have been made if it decides >> that such a use is warranted. >> >> WG members can take this information into account during the working >> group last call. >> >> Reminder: This working group last call has nothing to do with picking >> the mandatory-to-implement cipher suites in TLS. >> >> Cheers, >> Joe & Sean >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ >> [2] >> https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/ >> [3] >> https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/ >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
