[TLS]Re: Curve-popularity data?

[Bas Westerbaan <[e-mail]>]

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
grease has been removed. Recall X25519=29, X25519Kyber768=25497, P-256=23.
[1] "frac" is percents.

┌─────────────────frac─┬─sent───────┬─supported──────────────────────────────────────────┐
│    46.08025597692571 │ [29]       │ [23,24,29]
              │
│    19.10472730561162 │ [29]       │ [23,24,25,29]
             │
│   12.634492333471034 │ [29]       │ [23,24,25,29,30]
              │
│    9.969397483263833 │ [29,25497] │ [23,24,29,25497]
              │
│    7.245082433725522 │ [29]       │ [23,24,25,29,30,256,257,258,259,260]
              │
│   0.9836423280948468 │ [23,29]    │ [23,24,25,29,256,257]
             │
│   0.9693757351437323 │ [23,29]    │ [23,24,25,29,30,256,257,258,259,260]
              │
│   0.7147137542915519 │ [23]       │ [16,19,21,23,24,25,256]
             │
│   0.5387597287371817 │ [23]       │ [23,24,25]
              │
│   0.3216808337902684 │ [24]       │ [23,24]
             │
│   0.3077268972274922 │ [29]       │ [23,24,29,30]
             │
│   0.2895491193771448 │ [23]       │ [23,24,25,256,257,258,259,260]
              │
│   0.2310142062284145 │ [23,29]    │ [23,24,25,29]
             │
│  0.13238812679791004 │ [29]       │ [23,24,25,29,25497,65074]
             │
│   0.0837752734900604 │ [23]       │ [23]
              │
│ 0.057858939606985335 │ [29]       │ [23,24,25,29,256,257,258,259,260]
             │
│   0.0405672284711662 │ [29]       │ [23,24,25,29,30,249]
              │
│ 0.036025019042332365 │ [23]       │ [23,24]
             │
│ 0.027518977252528012 │ [23]       │
[9,10,11,12,13,14,22,23,24,25,256,257,258,259,260] │
│ 0.021650399459822143 │ [23,29]    │ [23,24,25,29,256,257,258,259,260]
             │
└──────────────────────┴────────────┴────────────────────────────────────────────────────┘

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. [2]

When we sent an empty ClientHello, advertising support for X25519,
X25519Kyber768, P-256, P-384 and P-521, those origins that support TLS 1.3
(and HelloRetryRequest [3]) picked as follows. We can call this server
preference.

96.7% X25519
1.8% P-384
0.7% P-256
0.54% X25519Kyber768
0.15% P-521

We also measure server support for each. (We send just the single keyshare
for the group and only advertise support for that group.)

97.6% P-256
97.0% X25519
94% P-384
89% P-521
0.54% X25519Kyber768

Best,

 Bas


[1] For your convenience link to the full list:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
[2] https://blog.cloudflare.com/post-quantum-to-origins
[3] About 1% of origins fails to do HelloRetryRequest.


On Mon, Jun 3, 2024 at 12:09 PM Martin Thomson <[e-mail]> wrote:

> 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 size: 1024 0.25% (!), 2048 98.45%, 3072 0.26%, 4096 1.03%
>
> Authentication:
>   RSA Sign 70.10%, ECDSA 29.14%, RSA KEA 0.76%
> ECDSA curve:  P-256 99.69%, P-384 0.31%
> RSA size: 1024 0.09% (!), 2048 97.22%, 3072 0.28%, 4096 2.41%
>
> We do not expose Ed25519 signing in TLS at this stage, even though we
> could use delegated credentials so that it could be enabled without needing
> certificate support.
>
> On Sun, Jun 2, 2024, at 19:47, D. J. Bernstein wrote:
> > Information about the popularity of specific cryptosystems plays a role
> > in decisions of what to standardize and deploy. I've been pointed to a
> > surprising statement (quoted below) regarding popularity of curves, in
> > particular in TLS handshakes. The statement is from one of the current
> > TLS co-chairs, a month before the co-chair appointment. I'm wondering
> > what data the statement is based on; the statement doesn't have a
> > description of the data sources, and the statement seems impossible to
> > reconcile with various public statements that have clear data sources.
> >
> > A specific reason that I'd like to resolve this is that I'm concerned
> > about the impact on post-quantum deployment. To explain:
> >
> >    * We're failing to protect confidentiality of most user data against
> >      future quantum attacks---but switching to a post-quantum system has
> >      an unacceptably high chance of making security even worse. See
> >      https://cr.yp.to/papers.html#qrcsp for how much has been broken.
> >
> >    * The obvious path forward is to immediately roll out ECC+PQ hybrids,
> >      as illustrated by X25519+sntrup761 in OpenSSH, X25519+ntruhrss701
> >      in ALTS, X25519+kyber768 in https://blog.cloudflare.com/pq-2024,
> >      X25519+kyber512 in
> >
> https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/
> ,
> >      etc. Then we're not making security worse, and _hopefully_ we're
> >      making it better.
> >
> >    * This still leaves the challenge of minimizing post-quantum risks.
> >      That's hard enough without the combinatorial explosion of combining
> >      each post-quantum option with a profusion of curves. Adding many
> >      curve choices is the sort of thing that _sounds_ simple until you
> >      start writing software, tests, etc. (I designed X25519 after
> >      suffering through implementing an example of NSA/NIST ECDH; see
> >      https://cr.yp.to/nistp224.html and the accompanying talks. NSA's
> >      harder-to-implement approach to ECC also ends up more likely to
> >      fail later; see, e.g., https://blog.cr.yp.to/20191024-eddsa.html.)
> >
> > Here's the specific statement I'm asking about:
> >
> >    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 the internet. So
> >    certificates, TLS, handshakes, all of that is like 70 plus percent
> >    negotiated with the P 256 curve.
> >
> > Last I heard, _certificates_ hadn't upgraded to allowing Ed25519 yet.
> > My question is about the "handshake" claim, and more broadly about the
> > "internet" and "world" claims.
> >
> > Examples of why I find the above TLS-handshake claim surprising:
> >
> >    *
> https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/
> >      (2019) says that "the most commonly used key exchange algorithm
> >      (according to Cloudflare's data) is the non-quantum X25519".
> >
> >    * https://blog.cloudflare.com/post-quantum-for-all/ (2022) says that
> >      "Almost every server supports the X25519 key-agreement and almost
> >      every client (98% today) sends a X25519 keyshare."
> >
> >    * https://eprint.iacr.org/2023/734 recorded TLS connections from many
> >      different apps and noted that X25519 was used in "the vast majority
> >      of the recorded handshakes".
> >
> >    * https://blog.cloudflare.com/pq-2024 says "Today almost all traffic
> >      is secured with X25519, a Diffie–Hellman-style key agreement".
> >
> >    * The handshake simulations in, e.g.,
> >
> >
> https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=142.250.217.142&hideResults=on&ignoreMismatch=on
> >      show current browsers using X25519 (while showing older client
> >      software using P-256). Clicking on random servers listed on the
> >      same site also consistently shows X25519.
> >
> > To be clear, this isn't saying that _all_ handshakes are using X25519.
> > NIST didn't manage to standardize Ed25519 until 2023, and still hasn't
> > managed to standardize X25519, so probably it's not too hard to find
> > servers that insist on P-256 for "FIPS compliance". I figured I'd be
> > able to give easy examples of this by trying nist.gov and nsa.gov---
> >
> >
> >
> https://web.archive.org/web/20240602150722/https://www.ssllabs.com/ssltest/analyze.html?d=nist.gov&s=129.6.13.49
> >
> >
> https://web.archive.org/web/20240602151119/https://www.ssllabs.com/ssltest/analyze.html?d=nsa.gov
> >
> > ---but it turns out that both of them end up using X25519, unless you're
> > connecting to nsa.gov with a client that doesn't support TLS 1.3.
> >
> > More broadly, Nicolai Brown's pages
> >
> >    https://ianix.com/pub/curve25519-deployment.html
> >    https://ianix.com/pub/ed25519-deployment.html
> >
> > include a long list of applications of X25519 and Ed25519. Spot-checks
> > confirm the overall accuracy of the list, and find many applications
> > where Curve25519 is the only curve, including big applications such as
> > WhatsApp and WireGuard.
> >
> > I'm also aware of some applications where P-256 is the only option. I
> > would guess that https://security.apple.com/blog/imessage-pq3/ is now
> > the biggest P-256 application. But I don't know how one would reach a
> > conclusion that "P 256 is most popular curve on the internet".
> >
> > ---D. J. Bernstein
> >
> >
> > _______________________________________________
> > TLS mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>