What key exchange mechanism should be used in TLS?

Question

There are many key exchange mechanisms that can be used in TLS. Among them are RSA, ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, ECDHE_RSA and others. Which of these are more cryptographically secure and can be used for securing connection with web site?

Answer 1

You may use a key exchange (as part of a cipher suite) only if the server key type and certificate match. To see this in details, let's have a look at cipher suites defined in the TLS 1.2 specification. Each cipher suite defines the key exchange algorithm, as well as the subsequently used symmetric encryption and integrity check algorithms; we concentrate here on the key exchange part.

• RSA: the key exchange works by encrypting a random value (chosen by the client) with the server public key. This requires that the server public key is an RSA key, and that the server certificate does not prohibit encryption (mainly through the "Key Usage" certificate extension: if that extension is present, it must include the "keyAgreement" flag).

• DH_RSA: the key exchange is a static Diffie-Hellman: the server public key must be a Diffie-Hellman key; moreover, that certificate must have been issued by a Certification Authority which itself was using a RSA key (the CA key is the key which was used to sign the server certificate).

• DH_DSS: like DH_RSA, except that the CA used a DSA key.

• DHE_RSA: the key exchange is an ephemeral Diffie-Hellman: the server dynamically generates a DH public key and sends it to the client; the server also signs what it sends. For DHE_RSA, the server public key must be of type RSA, and its certificate must be appropriate for signatures (the Key Usage extension, if present, must include the digitalSignature flag).

• DHE_DSS: like DHE_RSA, except that the server key has type DSA.

• DH_anon: there is no server certificate. The server uses a Diffie-Hellman key that it may have dynamically generated. The "anon" cipher suites are vulnerable to impersonating attacks (including, but not limited to, the "Man in the Middle") since they lack any kind of server authentication. On a general basis, you shall not use an "anon" cipher suite.

Key exchange algorithms which use elliptic-curve cryptography are specified in another RFC and propose the following:

• ECDH_ECDSA: like DH_DSA, but with elliptic curves: the server public key must be an ECDH key, in a certificate issued by a CA which itself was using an ECDSA public key.

• ECDH_RSA: like ECDH_ECDSA, but the issuing CA has a RSA key.

• ECDHE_ECDSA: the server sends a dynamically generated EC Diffie-Hellman key, and signs it with its own key, which must have type ECDSA. This is equivalent to DHE_DSS, but with elliptic curves for both the Diffie-Hellman part and the signature part.

• ECDHE_RSA: like ECDHE_ECDSA, but the server public key is a RSA key, used for signing the ephemeral elliptic-curve Diffie-Hellman key.

• ECDH_anon: an "anon" cipher suite, with dynamic elliptic-curve Diffie-Hellman.

---

So, what shall you choose, for a Web site ? Your main constraints are:

• You want a cipher suite which is supported by most clients; in practice, this rules out elliptic curve cryptography (elliptic curves are mightily cool, but not well supported yet in the field -- consider that according to gs.statcounter, as of September 2011, 40% of client systems still use Windows XP, and almost 5% use IE 7.0).

• You want a cipher suite which is compatible with your server key type and certificate. This, in turn, depends on what the CA accepts (the CA which sold you the certificate). 99.9% of the time, this means RSA. Everybody does RSA. Diffie-Hellman keys in certificates, and DSA signatures, used to be promoted by NIST (the US federal agency which deals with such matters) because there was a patent on RSA; but that patent expired in 2000. Diffie-Hellman (as part of certificates) is specified by ANSI X9.42, a standard which is not free (so opensource free-time developers are reluctant to implement it) and not all that clear either. So nobody really uses Diffie-Hellman in certificates. DSA is more widely supported (its defining standard is free and quite readable) but not to the point of being non-anecdotic when compared to RSA.

• You do not want to use an "anon" suite because that's insecure against active attackers, and most client browsers have the "anon" suites deactivated by default.

So you choice is basically between "RSA" and "DHE_RSA". The latter may have a slightly higher computational cost, although you would need to have at least a few hundred new connections per second to actually see a difference (I insist on the "new": since TLS includes an abbreviated handshake which can build on the key exchange of a previous connection, the actual key exchange with asymmetric cryptography only occurs once per new client browser in the last minute). So, in practice, no measurable difference on the CPU load between RSA and DHE_RSA.

DHE_RSA offers something known as Perfect Forward Secrecy, a pompous name for the following property: if your server gets thoroughly hacked, to the point that the attacker obtains a copy of the server private key, then he will also be able to decrypt past TLS sessions (which he recorded) if these sessions used RSA, while he will not be able to do so if these sessions used DHE_RSA. In practice, if the attacker could steal your private key, then he probably could read the 10000 credit card numbers in your site database, so there is little reason why he should even bother recording and decrypting previous sessions because this would yield only a dozen extra numbers or so. PFS is mathematically elegant, but overhyped. If it still a nifty acronym and can make a great impression on the weakly-minded, as part of a well-thought public relations campaign.

---

Summary: use DHE_RSA.