On Mon, Jun 3, 2024 at 10:49 AM Loganaden Velvindron <logana...@gmail.com>
wrote:
>
>
> 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.
>
There are also companies in the US which ship X25519, but as Andrei says,
there are also situations where P-256 is required. The question is rather
what the minimum set of algorithms we need is. My point is that that has to
include P-256. It may well be the case that it needs to also include X25519.
-Ekr
>
>
> 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
