On Mon, Jun 3, 2024, 20:59 Andrei Popov <Andrei.Popov=
40microsoft....@dmarc.ietf.org> wrote:
> 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.
>
>
>
There are companies from africa that swear by 25519. They build products
that ship with those.
In this part of the world, companies (and people) aren't so focused on
compliance with NIST standards as north american companies are.
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> 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
>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
