> 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 <stephen.farr...@cs.tcd.ie> Sent: Wednesday, June 5, 2024 12:20 AM To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>; tls@ietf.org 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. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
