D. J. Bernstein wrote:
>Again, I understand that certificates haven't upgraded t allowing Ed25519 yet;
The WebPKI forbids EdDSA and my understanding is that TLS library support is
lacking [1], but otherwise I don't think there are any problems with using
EdDSA certificates [2] in general. Ericss
D. J. Bernstein writes:
>Sorry, can you please clarify which statistics would be heavily skewed by
>Chrome retrying connections to 0.6% of servers?
Since Chrome does 25519 but not the MTI P256 in its client hello, and Chrome
and the Chrome code base are everywhere, this will skew the statistics
Peter Gutmann writes:
> This will also heavily skew any statistics
Sorry, can you please clarify which statistics would be heavily skewed
by Chrome retrying connections to 0.6% of servers?
Here's why I'm saying 0.6% here: My understanding is that you're talking
specifically about connections from
Dennis Jackson writes:
> This was used by Eli Biham and Lior Neumann to break Bluetooth pairing
> standard back in 2018 [1]. The Bluetooth standard previously said
> implementers could choose to do full point validation or always use
> ephemeral keys, and folks opted for the less complex choice. Th
On Mon, Jun 3, 2024 at 3:02 PM Peter Gutmann
wrote:
> Filippo Valsorda writes:
>
> >The most important performance consideration in TLS is avoiding Hello
> Retry
> >Request round-trips due to the server supporting none of the client's key
> >shares.
>
> This is already a huge problem with Chrome
Filippo Valsorda writes:
>The most important performance consideration in TLS is avoiding Hello Retry
>Request round-trips due to the server supporting none of the client's key
>shares.
This is already a huge problem with Chrome because it doesn't support any MTI
curves in its client hello, whic
David Adrian writes:
> I believe we were also discussing _certificates_
Yes, I quoted that from the outset:
P 256 is the most popular curve in the world besides the bitcoin
curve. And I donât have head to head numbers, and the bitcoin curve
is SEC P, but P 256 is most popular curve on
Bas Westerban wrote
>X25519+ML-KEM will be acceptable for FIPS
Yes. I don’t see any need for P-256 hybrids. X25519+ML-KEM or just ML-KEM will
both be acceptable for FIPS and should be enough for most users.
I think it is very important to choose very fast algorithms. More ephemeral key
exchange
Given that it will be some years before we have verified modules with
ML-KEM, it seems like P-256 + ML-KEM (as an evolution of P-256 + Kyber)
will have utility for some time, for those who care about validation.
--Richard
On Mon, Jun 3, 2024 at 4:32 PM Bas Westerbaan wrote:
> X25519+ML-KEM will
X25519+ML-KEM will be acceptable for FIPS, just like P-256+Kyber is today.
We just need to wait for the final standard, and (crucially) for the
verified modules with ML-KEM.
On Mon, Jun 3, 2024 at 8:56 PM Stephen Farrell
wrote:
>
> I'm afraid I have no measurements to offer, but...
>
> On 03/06/
Internet-Draft draft-ietf-tls-key-share-prediction-00.txt is now available. It
is a work item of the Transport Layer Security (TLS) WG of the IETF.
Title: TLS Key Share Prediction
Author: David Benjamin
Name:draft-ietf-tls-key-share-prediction-00.txt
Pages: 7
Dates: 2024-
On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell
wrote:
>
> I'm afraid I have no measurements to offer, but...
>
> On 03/06/2024 19:05, Eric Rescorla wrote:
> > 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 th
I'm afraid I have no measurements to offer, but...
On 03/06/2024 19:05, Eric Rescorla wrote:
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.
Yep, the entirely obvi
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 X2
On Mon, Jun 3, 2024 at 10:49 AM Loganaden Velvindron
wrote:
>
>
> On Mon, Jun 3, 2024, 20:59 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, howev
On Mon, Jun 3, 2024, 20:59 Andrei Popov 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 securit
Dan,
> I'm still puzzled as to what led to the statement that
I quoted at the beginning:
I was also hosting the same podcast you were quoting, and I believe we were
also discussing _certificates_, which have the following breakdown
according to Censys:
SHA512-RSA0.002%
SHA384
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
Sent
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.
Thanks to Martin Thomson, Bas Westerbaan, and David Adrian for the
measurement data. I'm still puzzled as to what led to the statement that
I quoted at the beginning:
P 256 is the most popular curve in the world besides the bitcoin
curve. And I donât have head to head numbers, and the bitc
Hi! WGLC ends on Wednesday. I know this I-D is not all that exciting and most
of the “discussion" was about whether to adopt the I-D at all, but it would be
great if we had a couple of more people chime in. If you remember, when we
used the show of hands tool to help determine whether there wa
Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been
submitted (and discussed) that include changes to normative language:
- #1343: Forbid the sender from sending redundant update_requested KeyUpdates
https://github.com/tlswg/tls13-spec/pull/1343
- #1345: Forbid the sender from
On 02/06/2024 22:02, Filippo Valsorda wrote:
Third, we learned to make key shares always ephemeral which makes
invalid curve attacks irrelevant.
Although using ephemeral keys does effectively prevent key recovery
through invalid points, you can still use invalid points to perform
confinement
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+Ky
On Mon, Jun 3, 2024 at 4:02 PM Filippo Valsorda
wrote:
> 2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
>
> 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 happe
2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
> 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
On Mon, 3 Jun 2024 at 01:03, Filippo Valsorda wrote:
>
> I expect X25519 to be the most commonly selected (as opposed to supported)
> TLS key exchange on the open Internet, due to browsers preferring it for its
> marginal performance benefit. This is not a popularity contest though and
> that's
On Mon, Jun 3, 2024 at 3:24 PM Salz, Rich
wrote:
> Thank you for collecting and sharing these numbers! I think this here is
> the most interesting bit in terms of curve popularity, since any difference
> in CPU time is ultimately marginal compared to the cost of a HRR.
>
>
>
> I’m not so sure.
Thank you for collecting and sharing these numbers! I think this here is the
most interesting bit in terms of curve popularity, since any difference in CPU
time is ultimately marginal compared to the cost of a HRR.
I’m not so sure. This is really CDN to origin, or server-to-server traffic.
Yo
2024-06-03 14:38 GMT+02:00 Bas Westerbaan :
> We're not just a server, but also a client proxying requests to our
> customer's origins. We routinely scan customer's origin servers for their
> support of keyshares. [...]
>
> We also measure server support for each. (We send just the single keysha
Numbers from Cloudflare server-side in the last hour. Restricted to TLS 1.3
and counting by handshake. "sent" column lists the group identifiers for
the keyshares sent by the cleint, and "supported" lists the identifiers for
the groups the client reports being supported. Both lists are sorted, and
Filippo Valsorda writes:
> For what it's worth, implementing P-256 these days is way easier than
> when X25519 was designed. First, Renes, Costello, and Batina published
> complete formulas for it in https://eprint.iacr.org/2015/1060
Actually, Lange and I published complete formulas for P-256 six
Filippo Valsorda wrote:
>Third, we learned to make key shares always ephemeral which makes invalid
>curve attacks irrelevant.
Have we? TLS 1.3 key shares are semi-static and may be reused an unlimited
number of times.
IKEv2 and (D)TLS 1.3 are doing quite a lot of questionable optimizations such
On Mon, Jun 3, 2024, at 11:23, Filippo Valsorda wrote:
> Thank you for sharing those! Could you filter down to TLS 1.3 only
That's not possible, sadly.
> (since we are not going to add hybrids to TLS 1.2 anyway)? I assume
> that after filtering to TLS 1.3, any non-X25519 connections are Hello
2024-06-03 12:07 GMT+02:00 Martin Thomson :
> Some numbers from our telemetry. This is purely connection-volume-based (so
> sites with lots of connections will be over-represented), but overall fairly
> stable.
>
> Key exchange:
> ECDHE 99.21%, RSA 0.76%, ECDHE+KYBER: 0.03%
> ECDHE curve: X25
Some numbers from our telemetry. This is purely connection-volume-based (so
sites with lots of connections will be over-represented), but overall fairly
stable.
Key exchange:
ECDHE 99.21%, RSA 0.76%, ECDHE+KYBER: 0.03%
ECDHE curve: X25519 84.50%, P-256 14.03%, P-384 0.93%, P-521 0.53%
RSA siz
Hi,
I think it is very hard to get any reliable statistics on what is the most
popular curve in the world. I agree with you that X25519 is now used in the
vast majority of TLS handshake on the Web, which is great. But curves are used
outside of TLS, and TLS is a lot bigger than just the Web, an
37 matches
Mail list logo
