Botan TLS server handles missing ECC extensions in client hello incorrectly

[falko-strenzke]

If the TLS client doesn't send the supported curves extension, Botan declines the use of ECC suites during the handshake. This is incorrect / unnecessary, see https://tools.ietf.org/html/rfc4492#section-4

A client that proposes ECC cipher suites may choose not to include these extensions. In this case, the server is free to choose any one of the elliptic curves or point formats listed in Section 5. <<

[randombit]

The problem is we don't distinguish in the server between a client not sending the extension and them sending an empty extension. But looking at the definition of EllipticCurveList from RFC 4492 I see that an empty ECC extension is not even valid, at least one NamedCurve element is required if the extension is present at all.

This aspect of the specification doesn't seem too well thought out to me, since in practice a client doing this probably doesn't support actually support all of the curves that could be negotiated (for instance Ed448 or an arbitrary binary curve, or even Brainpool curves for that matter). But I guess we can treat ECC suites without a supported groups extension as an implicit indicator for P-256 + P-384 with relative safety.