On Mon, Jun 3, 2024 at 3:02 PM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> Filippo Valsorda <fili...@ml.filippo.io> 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, which means it triggers a hello retry on > *every* > *single* *connect* to a compliant implementation. > RFC 8446 section 9.1: > A > TLS-compliant application MUST support key exchange with secp256r1 > (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. Section 9.3: > - If containing a "supported_groups" extension, it MUST also contain > a "key_share" extension, and vice versa. An empty > KeyShare.client_shares vector is permitted. Looking at a ClientHello from Chrome, I see secp256r1 in the supported_groups extension. By my understanding of the RFC, this ClientHello meets the MTI requirements in RFC 8446. I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves be present in the key_share extension if that extension is non-empty. (The RFC is explicit about permitting the extension to be empty.) > > This will also heavily skew any statistics, because Chrome's noncompliant > behaviour will show up almost everywhere. So I'm not sure that a > popularity > poll on curves has much meaning. > > 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
