Usage of Ephemeral Diffie-Hellman ciphers in 2015 and beyond

Question

In determining TLS standards for my company, I have come to wonder why all recommendations still suggest the use of the Ephemeral Diffie-Hellman TLS ciphers starting in TLS_DHE_xxx

Background and research

After doing a lot of research, I have found the following.

• TLS_DHE_xxx cipher suites are not used much in the wild - Only one site (Wikipedia.org) in the top ten sites on Alexa.com actually uses them. None of the others do, instead relying on TLS_ECDHE_xxx or TLS_RSA_xxx ciphers. From this, I can only deduce that there are not many browsers out there that are affected by not using these ciphers, otherwise these large sites would be cutting people off.
• "Enterprise" web server products that I have looked at do NOT support the TLS_DHE_xxx cipher suites. Oracle iPlanet Web server, Oracle HTTP Server(OHS) and IBM HTTP Server(IHS) do not support these suites. (Although OHS/IHS are both based off Apache, they both use their own TLS implementations instead of OpenSSL.) If support of these cipher suites was critical, these Enterprise offerings would surely need to support them.
• The 'de-facto' source for suggested cipher suites seems to be the Mozilla Server_Side_TLS guide, but the intent of this document is to help Mozilla sysadmins in configuring various Mozilla sites. It was NOT originally intended to be a general standard for the Internet-at-large, even though it has fallen into that role. Also, this document makes no mention of why the TLS_DHE_xxx ciphers are needed.
• Since the LogJam attack came into the wild, sysadmins have had to ensure that their DH parameters are correctly adjusted. If this cipher is not really needed, this is wasted effort. Simply removing the cipher would be a better solution that will not potentially cause problems later (Say someone creates a new TLS listener and forgets the DH parameters).
• Over the coming years, the Internet will be moving towards ECDSA certificates. There are no TLS_DHE_xxx cipher suites that support ECDSA certificates (Only TLS_ECDHE_xxx cipher suites do). It seems to me, given this, that these cipher suites will be going away anyway.

• Looking at the supported cipher suites for browsers on ssllabs.com, it is apparent that there are no significant browsers that would choose TLS_DHE_xxx ciphers over the Elliptic Curve equivalents. Every browser, even on Wikipedia.org that supports TLS_DHE_xxx ciphers, will instead choose a TLS_RSA or TLS_ECDHE cipher suite.

  Notable exceptions to this are Android 2.3.7 and below, IE 8 on XP, Java 6u45 and OpenSSL 0.9.8y. Of these, Android 2.3.7, OpenSSL 0.9.8y and Java 6u45 will choose a TLS_DHE cipher, and even then, the latter will not support DH parameters greater than 1024 bits (Which is recommended since the LogJam attack). IE 8 on XP will not even choose the TLS_DHE ciphers, so that browser is moot in this context.

  Effectively, the above paragraph results in the fact that the only advantage to enabling TLS_DHE_xxx ciphers is that Android 2.3.7 and OpenSSL 0.9.8y clients are able to connect using Perfect Forward secrecy. It is my finding that these fringe-case clients are the only reason to support these ciphers. If this is indeed the case, it seems that going forwards, there is no purpose in including these cipher suites unless you explicitly wish to support PFS for these browsers. Note that all of these browsers will still connect using TLS_RSA_xxx ciphers if the correct ones are available, but without PFS.

Edit:

After some great feedback from Mike and Michał, I have decided to add some further points to my research that I would like to be considered when answering this question.

Although they both raised valid points, in my opinion, they both point to somewhat 'fringe' cases when considered on the Internet in general as we know it today.

• Trust Issues with EC ciphers.

  I had considered this during my initial research, but forgot to add it to the original question. Some people do not trust the standard EC curves defined in RFC 4492. This could result in a number of possible outcomes to my question.

  1. The server owner distrusts ECDHE ciphers but leaves them enabled along with DHE ciphers (As per the Mozilla TLS guide). In this case, the DHE ciphers will never be used by anything other than the fringe-case browsers mentioned above.

  2. The server owner has no opinion on the trustworthiness of ECDHE ciphers and leaves the DHE ciphers there in case the client distrusts ECDHE. In this case, the only users that will have disabled ECDHE are likely advanced users that distrust them due to the NSA involvement. It could also be assumed that such a user would want Perfect Forward Secrecy and therefore be restricted to only using DHE ciphers. However half of the web servers on the internet are not using DHE ciphers so these users would have a hard time doing pretty much anything (And as they are advanced users, they would know why they cannot google or visit stack exchange or most top ranked sites).

  This seems like a fringe case of users that do not need to be considered for the 'typical' web site.

  3. If the server owner completely distrusts ECDHE ciphers, then she should simply not enable them, instead only enabling DHE ciphers. This is a good scenario for using DHE ciphers. However, I have not found any sites yet that only support DHE and not ECDHE.

  This makes this seem like a 'fringe case' and not applicable to typical TLS setups. It could certainly be argued in any standard that if ECDHE trustworthiness is an issue, that DHE should be considered instead.

• Curve Compatibility Issues

  Having now learned about how the "Supported Elliptic Curves Extension" works, I can now see how this could be a consideration for using DHE ciphers. However, I still feel that this is a fringe case. Consider these scenarios:

  1. The server owner wishes to use custom curves that are not widely supported in common browsers. She uses a TLS configuration that specifies the custom curve and leaves the standard curves in place also. In this case, browsers that do not support the custom curves will still connect using ECDHE and the standard curves. In no case, other than the outdated fringe-case clients mentioned above, would any browser connect using DHE so specifying them would not be necessary.

  2. The server owner wishes to only use custom/nonstandard curves that are not widely supported in common browsers. She uses a TLS configuration that specifies the custom/nonstandard curve for ECDHE and not the standard curves. Most current browsers would not support the custom/nonstandard curve and would need to fall back to DHE to maintain PFS. This is a good scenario for supporting DHE ciphers as a fallback for those that do not support good ECDHE curves. I still feel that this is a fringe case as common TLS servers do not allow such configuration (yet).

  This may become less of a fringe case in the future if more servers start supporting the option of specifying which curves you wish to use.

Summary:

I have been searching for some time for reasons to include or to exclude these ciphers and have come up with nothing, other than my own research that I have done myself. I can't help feeling that I must be missing something, so my question is this:

• Is there a valid and current reason, given the above, that TLS_DHE_xxx ciphers should be used in a modern TLS configuration for general use in 2015 and going forwards?

Answer 1

1. Some servers may use curves likes Curve25519, Curve448 or P-521. Clients not supporting it will need alternative key exchange methods.
2. Some people don't trust NSA-blessed NIST curves like P-256 and P-384 (check out SafeCurves to see why) and might want to block ECDHE until safer curves get adopted.
3. Some people don't trust ECC at all and DHE is (SFAIK) the only viable alternative to have PFS without ECC.
4. LogJam is result of using weak dhparam, not a problem in DHE itself.
5. I am not so sure if ECDSA will (or even should) replace RSA signatures. Creating RSA signature is slower, but signature validation is faster than in case of ECDSA. We've also had a few fails related to ECDSA implementations and resulting in private key disclosures (PS3, OpenSSL, Android). Not a problem from scientific point of view, but in real world it's a technology-related risk we should consider.

PS Both ECDHE and DHE will be useless in post-quantum world, so we should think about solutions like SIDH (PFS for post-quantum cryptography) when considering key exchange methods in a bit more distant future.

Answer 2

Some people do not trust the curves that are used for ECDHE, believing them to have been compromised by the NSA or some other agency -- see for example this comment by Bruce Schneier stating that he now prefers classic discrete log crypto instead of ECC. If you don't trust ECDHE then DHE is the only algorithm that provides perfect forward secrecy, and so should be your preferred choice.

Answer 3

First a note on how the ciphersuite selection works.

• The client sends a list of ciphersuites in order of preference.
• The server picks one of them to use for the session.

According to the standard servers are supposed to respect the client's preference. In reality servers tend to ignore the clients preferences as server admins believe (rightly or wrongly) they know better than the clients which cipersuites are best.

Suppose I am a server admin with the following goals:

1. I want forward-secrecy on all clients that support it.
2. I want the best symmetric cryptography the client supports.
3. I want to use one certificate on my server, not mess arround with seperate RSA and ECDSA certificates.

I don't think these goals are unusual for a privacy-minded server admin.

Given these critera and according to ssl labs DHE fills some gaps.

• For some strange reason IE 11 on win7 and win8 is missing some cipher combinations. It supports RSA based authentication (which you want so you can use normal certificates), It supports AES GCM and it supports ECDHE but for some strange reason it apparently doesn't support the combination of the three.
• Andriod 2.x (still depressingly common) supports DHE but not ECDHE.

Since there is no reason to believe DHE with sufficiently large primes is insecure I would therefore leave it enabled if supported.

If it is enabled you should make sure a sufficiently large prime is used. My general guideline would be to make your DSA prime the same size as your RSA keys.

I would generally place DHE ciphersuites just below the corresponding EDHE ciphersuites in the preference order.