[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[Andrei Popov <[e-mail]>]

> if, when using a hybrid KEM, we're heading to a world where one large set of clients emit x25519 and x25519+pq and another large set emit p256 and p384+pq?

We are already in the world where a large set of servers will HRR to get the client to send a 25519 key share, while another large set of servers will HRR to get the client to send a NIST curve key share. TLS 1.3 with HRR is somewhat higher-latency than the TLS 1.2 2-RTT handshake, so enabling TLS 1.3 can increase connection latency for some deployments.

With traditional groups, clients have an option of offering both 25519 and NIST key shares. With PQC/hybrids, this will likely become impractical, this is why I believe TLS key share prediction (https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-00.html) becomes more important.

Cheers,

Andrei

-----Original Message-----
From: Stephen Farrell <[e-mail]> 
Sent: Wednesday, June 5, 2024 12:20 AM
To: John Mattsson <john.mattsson=[e-mail]>; [e-mail]
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?



On 05/06/2024 06:56, John Mattsson wrote:
> I think P-384 is the most required of the NIST P-curves.

I've heard that some. Oddly, I use a test server that only supports
p384 as a way to trigger HRR when testing ECH, which seems to work for most clients who test with my servers, so I wonder if, when using a hybrid KEM, we're heading to a world where one large set of clients emit x25519 and x25519+pq and another large set emit p256 and p384+pq?

I guess if that meant there wasn't a real need for much use of p256+pq that might be a small saving and worth documenting somewhere even if we do define a codepoint for p256+pq.

Cheers,
S.