Support ECDHE key agreement about s2n-tls HOT 4 CLOSED

I'll have to add two handshake extensions: the Supported Elliptic Curves Extension, and the Supported Point Formats Extension [ECC]:

Servers implementing ECC cipher suites MUST support these extensions, and when a client uses these extensions, servers MUST NOT negotiate the use of an ECC cipher suite unless they can complete the handshake while respecting the choice of curves and compression techniques specified by the client.

A part of those extensions is (1) choosing a preference list on the client side and (2) selecting the curve and the point format from the client preference list on the server side. Anybody has ideas on how it should be done? What should be our sane defaults for both client and server sides?

from s2n-tls.

There seems to be an emerging consensus that using custom curves is a bad idea, which at least leaves just the named curves to support. I think that means that our point format extension support can be very minimal. In terms of curves, 256p1 seems to be supported by just about everyone, so maybe we can start with just 256p1 as a named curve?

from s2n-tls.

Sounds like a simple and reasonable first version, I'll do that.

from s2n-tls.

384p1 is also popular and well supported by browsers. Anything outside of those two has limited support.

from s2n-tls.