+1 . I was of the impression that https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-10#name-iana-considerations was going to get final codepoints for both combinations.
Also, “PQ hybrid automatically FIPSed with P256” is an important factor. Using a FIPS certified ML-KEM implementation in X25519+MLKEM would address this too, but certified implementations of ML-KEM are 2.5+ years out due to NIST’s FIPS queue. From: Eric Rescorla <e...@rtfm.com> Sent: Monday, June 3, 2024 12:31 PM To: David Adrian <davad...@umich.edu> Cc: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org>; tls@ietf.org Subject: [EXTERNAL] [TLS]Re: Curve-popularity data? 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. 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
