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> 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>
> wrote:
>
>> 2024-06-03 15:34 GMT+02:00 Bas Westerbaan <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
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
