# With TLS and ECDHE, how does curve selection work?

Given that a TLS client and server have already agreed upon ECDHE for session key establishment, how does the selection of the actual elliptic curve ("domain parameters") being used for deriving the DH keys work?

Is the curve somehow negotiated and if so how does that work (in the context of TLS)?

-

As described in section 5.1 of RFC 4492, the client announces what curves it supports in an extension message, included in the ClientHello message. This gives the server the possibility to check whether client and server both support at least one specific curve, before choosing whether elliptic curves will be used at all.
Then the server chooses the curve. The curves named in the Supported Elliptic Curves extension are ordered by client preferences, so a courteous server may elect to follow the client's preferences, i.e. the first one in the client's list that the server also supports (where "supports" means "has the code for it, and deems it acceptable"). But, really, the server chooses.
Thanks for explaining! Regarding negotiation: what you describe refers to named curves (IANA registered) with domain parameters built into the implementation, right? Do you know any TLS implementation that supports arbitrary_explicit_prime_curves which the RFC also describes? Since, e.g., OpenSSL does not: github.com/openssl/openssl/blob/master/ssl/s3_clnt.c#L1754, github.com/openssl/openssl/blob/master/ssl/t1_lib.c#L419 - I am asking since of safecurves.cr.yp.to and those NIST defined might be .. well, you know where I am heading;) – oberstet Oct 26 '13 at 23:36