ECDHE_RSA_WITH_AES_128_GCM_SHA256 - How to determine ECDHE Key Length?

Question

Server: SSL Certificate, 2048-bit RSA Public Key, Signature Algorithm is sha256RSA

What am I missing here? !

• I've scoured the RFC's, and I have yet to find anything on how to determine the ECDHE key size (or any key exchange algorithm key size) in a TLS cipher suite. I need to confirm that ECDHE is at least 256 bits for compliance reasons.

• In both RFC8422 and RFC4492 it's emphasized that for ECDHE_RSA, the Certificate MUST contain an RSA public key... boom got it, now how do I determine the curve's key length?

I don't understand why in SSH, a key exchange algorithm like "ecdh-sha2-nistp384" has the curve size in it (which also determines the hash size), bit in a TLS cipher suite this is not the case.

• The same thing goes for DHE_RSA_WITH_AES_128_GCM_SHA256 - How can I confirm that Diffie Hellman Ephermal is 2048 bits?

Is there other information I need to be looking at besides the Cert and the Cipher Suite? Do I need to dig into the code? Thanks in advance for any assistance with this!

Answer 1

(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 ssl_dhparam directive.

(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.

Answer 2

The specific curve or DH key length is not given in the cipher. The client simply supports a number of curves and can give these in the ClientHello (elliptic_curves extension), similar to how the client shows the supported ciphers. Similar the server has a number of curves and specific DH param configured and can align these with the curves offered by the client, similar to how a cipher selection is done.

With TLS 1.3 this is a bit different, i.e. the client assumes that the server will support specific curve(s) and already start the key exchange based on this assumption. It can fall back to the older behavior if this fails though.

See also With TLS and ECDHE, how does curve selection work? at Cryptography Stack Exchange.