I support this change, willing to implement it in the Windows TLS stack. We have thousands of customers concerned about increased latencies due to the enablement of TLS 1.3. The services they connect to require NIST curves and HRR is required to get TLS clients to send appropriate key shares. TLS 1.3 with HRR is somewhat higher-latency than TLS 1.2 full handshake, so TLS 1.3 deployment causes performance regressions for these customers.
(Of course, TLS key share prediction could override this, when the server's DNS record indicates no P256 support. The key share prediction draft can include this provision.) Cheers, Andrei -----Original Message----- From: Peter Gutmann <pgut...@cs.auckland.ac.nz> Sent: Wednesday, June 5, 2024 6:54 AM To: Eric Rescorla <e...@rtfm.com> Cc: tls@ietf.org Subject: [EXTERNAL] [TLS]Re: Curve-popularity data? Eric Rescorla <e...@rtfm.com> writes: >One more thing: we are finalizing RFC 8446-bis right now, so if there >is WG consensus to require that clients offer all MTI curves in the >key_shares of their initial CH, then that would be a straightforward text >change. That would fix things, something like saying a client has to provide at least one MTI cipher suite/signature/keyex in its client hello. There's only one MTI curve in 8446 so "all MTI curves" isn't a big deal. Peter. _______________________________________________ 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
