On Tue, Oct 7, 2025 at 9:28 AM Bas Westerbaan <[email protected]> wrote:
> 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. > I could live with that. -Ekr > 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]
