Correct; e.g., Microsoft Azure is one of these environments that require NIST curves. Some Azure services have exceptions allowing 25519, however generally 25519+MLKEM will not be acceptable for Azure services, for both regulatory and security reasons.
Cheers, Andrei From: Eric Rescorla <e...@rtfm.com> Sent: Monday, June 3, 2024 9:31 AM To: David Adrian <davad...@umich.edu> Cc: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org>; tls@ietf.org Subject: [EXTERNAL] [TLS]Re: Curve-popularity data? Indeed. I'd like to pull this back a bit to the question of what we specify/mandate. As I understand the situation, there are a number of environments that require P-256, so it seems like it would not be practical to just standardize/mandate X25519 + MLKEM if we want to get to 100% PQ algorithms. -Ekr On Mon, Jun 3, 2024 at 7:20 AM David Adrian <davad...@umich.edu<mailto:davad...@umich.edu>> wrote: I don't really see why popularity of previous methods is relevant to picking what the necessarily new method will be is, but from the perspective of Chrome on Windows, across all ephemeral TCP TLS (1.2 and 1.3, excluding 1.2 RSA), the breakdown is roughly: 15% P256 3% P384 56% X25519 26% X25519+Kyber On Mon, Jun 3, 2024 at 10:05 AM Filippo Valsorda <fili...@ml.filippo.io<mailto:fili...@ml.filippo.io>> wrote: 2024-06-03 15:34 GMT+02:00 Bas Westerbaan <b...@cloudflare.com<mailto:b...@cloudflare.com>>: More importantly, there are servers that will HRR to X25519 if presented a P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't have data at hand how often that happens. Are you saying that some of the 97.6% of servers that support P-256 still HRR to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported groups list, and that's BoringSSL's default behavior? I find that very surprising and would be curious about the rationale. _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org> _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
