Intent to Deprecate: DHE-based cipher suites
David Benjamin
(There was a previous “Intent to Deprecate” thread on net-dev and security-dev. The update is that we’re moving forward with it and adding a DevTools warning. Also the previous mail didn’t quite follow the template, so this iteration fixes that. Treat the old one as a "Pre-Intent" if you will.)
Primary eng (and PM) emails
davi...@chromium.org, awha...@chromium.org
Summary
We plan to end support for DHE-based cipher suites.
Motivation
Last year, we raised the minimum TLS Diffie-Hellman group size from 512-bit to 1024-bit. As mentioned then, 1024-bit is insufficient for the long-term. However, metrics reported that around 95% of DHE connections seen by Chrome use 1024-bit DHE. This, compounded with how DHE is negotiated in TLS, makes it difficult to move past 1024-bit.
In TLS’s ECDHE ciphers, the client advertises a list of supported curves alongside the cipher list. Servers can recognize if no curves overlap and instead select, say, a plain RSA cipher. This is undesirable, but it is preferable to using a broken curve.
DHE ciphers do not have this advertisement step. The server selects a DHE group without client input, often hard-coded in the server software. Should this group be insecure, clients cannot switch ciphers, even if the server had plain RSA (or ECDHE if mis-ordered) ciphers available. Rejecting weak DHE groups thus has abnormally high compatibility risk, and clients must be conservative in setting limits, despite security risks posed by weak groups. In the past, raising limits has broken more sites (ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY) than we’d have liked.
Conversely, it is difficult for servers to deploy more secure groups. There exist some older clients which reject groups larger than 1024-bit. This too is unadvertised, so servers deploying a larger DHE group risk interoperability issues with those clients.
Although there is a draft specification add group negotiation, it is still a draft and requires both client and server changes. Meanwhile, ECDHE is already widely implemented and deployed.
Given all this, we do not feel it is practical to continue supporting DHE.
Compatibility Risk
Servers which support only DHE ciphers will stop working in Chromium-based browsers. (Note this is fewer than servers which merely prefer DHE. Typically servers have other ciphers available. See usage information below.)
The latest versions of Safari on both OS X and iOS removed DHE support, so any affected sites are already inaccessible in Safari.
Though most have since been resolved, sites which became inaccessible due to ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY will work again with DHE deprecated.
Alternative implementation suggestion for web developers
Administrators should upgrade to ECDHE-based cipher suites. We recommend TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for most deployments. If ECDHE is unavailable, ensure a plain RSA cipher suite is enabled. This is not expected to require software updates, only a configuration tweak. We are not aware of any server software which implements only DHE ciphers.
Servers should also disable DHE-based ciphers if their software uses a weak group. This is not necessary for interoperability with future DHE-less versions of Chromium, but other clients which still support DHE will be vulnerable to the server’s DHE group, if too weak.
Usage information from UseCounter
In Chrome 49, we placed DHE under a fallback to determine how many sites would break. Current metrics from Chrome 49 report 0.014% of TLS connections require a DHE-based cipher. (This number includes any false positive noise due to spurious network errors. Fallback-based measurements are slightly imprecise.)
OWP launch tracking bug
Entry on the feature dashboard
https://www.chromestatus.com/feature/5752033759985664
Requesting approval to remove too?
No. We intend to remove the feature in milestone 52, after showing a deprecation warning in DevTools for 51.