(CW for anyone who wants to add additional cases)
The size/strength of ephemeral keys for DHE and ECDHE key exchanges in TLS can depend on
the protocol (version)
the server-side implementation code (usually a library), and sometimes configuration
the client-side implementation (ditto)
First, there is a significant difference between TLS 1.0 through 1.2 (plus SSL 3 for DHE, but no one should be using SSL 3 after 2015), versus TLS 1.3. In TLS through 1.2, where ciphersuites of the form you named in your title are used:
- DHE parameters are chosen by the server, usually with no input from the client other than offering ciphersuites that allow DHE at all; some server implementations allow configuring the parameters. RFC 7919 in 2016 allows the client, using extension 10 (see below), to specify a small set of standardized groups, all of which are at least 2048 bits, but I don't know any implementation that uses 7919 for <=1.2; see below about 1.3.
(Oracle/Open) Java JSSE server through 7 hardcoded DHE at 768 bits (except 512 bits for export suites, then still supported) and there are quite a few Qs on several Stacks about the problems this caused after Logjam, along with a client maximum of 1024. Java 8 changed default to 1024 bits with an option (system property) for up to 2048 (and also client max 2048). Java providers other than Oracle (like IBM, Android, and for a time Apple MacOSX) may have been or be different.
OpenSSL library requires server application either set parameters with
SSL_[CTX_]set_tmp_dh before seeing the ClientHello (although knowing the auth key-and-cert(s) configured) or use
SSL_[CTX_]set_tmp_dh_callback to provide a callback that will be called to set parameters for each handshake needing them. Some server programs that use OpenSSL pass this choice on to the user: Apache mod_ssl used to have a hardcoded default and now defaults to RFC 3526 "more IKE" groups of at least 2048 bits, but accepts 'custom' DHE params (in the PEM format OpenSSL commandline generates) along with a server cert in
SSLCertificateFile; nginx requires a separate
(Anyone want to add others?)
- ECDHE is generally limited to the 'named' (standardized) curves specified in RFC 4492 5.1.1 optionally modified by RFC 7027 and more recently (and thus not yet widely implemented) by RFC 8422. 4492 did define options for
arbitrary_explicit curves, but in practice no one used them, and 8422 deprecates them. If the client specifies extension 10, which was originally supported-curves and has now been repurposed as supported_groups, that limits the server choice and states a preference the server may follow; although extension 10 was technically optional in 4492, IME clients that implement ECDHE (and other ECC like ECDSA auth) at all do send it unless using the old SSL2-format 'compatibility' hello (as Java 6 and OpenSSL 0.9.8 did by default). But not many allow the content of extension 10 to be configured, and often it doesn't actually constrain the server.
(Oracle/Open) Java 7 server honors client preference, and if no extension uses P-256. I don't have source for 6 but it appears to do the same IF ECDHE is enabled at all -- which it isn't out of the box; JSSE protocol support is present but is only enabled if there is an underlying ECC provider which by default there is not and you have to add. To check: Java 8 up.
OpenSSL library originally required application to call
_set_tmp_ecdh[_callback] similar to DHE, but in 1.0.2 allows the application to call
_set_ecdh_auto which follows client preference (unless 'Suite B' is configured, which forces P-256 or P-384), and 1.1.0 up does 'auto' by default.
TLS 1.3 changes this substantially. The key exchange is not selected by the ciphersuite but instead controlled only by Hello extensions, and is completed entirely during the Hello exchange using those extensions, not separate ServerKeyExchange and ClientKeyExchange messages that extend into second flight as before. And it limits both DHE and ECDHE to a small set of standardized parameters: for DHE the 7919 groups which are all 2048 bit or more, and for ECDHE only the curves retained by 8422, which are (X9/SECG/NIST) P-256 P-384 P-521 and (Bernstein et al) X25519 X448.