Intent to deprecate: DHE-based cipher suites

2,328 views
Skip to first unread message

David Benjamin

unread,
Nov 18, 2015, 4:59:46 PM11/18/15
to net-dev, security-dev
We plan to end support for DHE-based cipher suites in a future release of Chrome. To begin the process and measure the impact, Chrome 49 will temporarily move DHE to a fallback.

Earlier this year, Chrome 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 report 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.

Although there is a draft specification to solve the negotiation issues, it is still a draft, while ECDHE is already widely implemented and deployed. Indeed DHE today is only negotiated for 2% of connections by Chrome. With these numbers, we do not feel it is practical to continue supporting DHE.

We do not expect to break all 2% of connections using DHE. We expect most servers also support plain RSA cipher suites and will continue working. To predict more accurately, we will temporarily use a fallback, as was done for RC4. Starting in Chrome 49, Chrome will not offer any DHE-based ciphers in the initial ClientHello. If that fails, we will retry with our current offering, so sites relying solely on DHE will not break at this time. (This is not a long-term solution as connections are only as secure as the weaker of the two configurations.)

This, however, means servers currently negotiating DHE will lose forward secrecy in Chrome 49. Servers 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 supported. Servers should also disable DHE ciphers. Even if ECDHE is preferred, merely supporting a weak group leaves DHE-capable clients vulnerable.

We will determine the exact removal schedule based on what we learn from this fallback.

David

zeev.t...@gmail.com

unread,
Nov 18, 2015, 6:47:47 PM11/18/15
to Security-dev, net...@chromium.org
Could you please amend "Servers should also disable DHE ciphers" to "Servers should disable DHE cipher suites if the group used for DHE is weaker than the private key"?

in...@leonklingele.de

unread,
Nov 19, 2015, 4:08:16 AM11/19/15
to Security-dev
"This, however, means servers currently negotiating DHE will lose forward secrecy in Chrome 49."

Not true. They will not lose FS if the server prefers DHE over ECDHE (NSA ECs!).
Also they will not lose Forward Secrecy if the server solely supports DHE suites.

Antonio Sanso

unread,
Nov 19, 2015, 3:46:02 PM11/19/15
to Security-dev, net...@chromium.org
Hi,

given the circumstances I would be all for deprecate DHE.
I wonder what would be left for forward secrecy though  given the fact NIST deprecated ECC.... http://blog.cryptographyengineering.com/2015/10/a-riddle-wrapped-in-curve.html

Yuhong Bao

unread,
Nov 19, 2015, 7:52:32 PM11/19/15
to Security-dev, in...@leonklingele.de
They are moving it to a reconnect fallback with the intention of killing DHE eventually, so it is true.

Eric Mill

unread,
Nov 20, 2015, 8:13:54 PM11/20/15
to Antonio Sanso, Security-dev, net-dev
For the clarity of the thread, it's NSA -- not NIST -- that posted the message about transitioning away from Suite B.

-- Eric

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.



--
Reply all
Reply to author
Forward
0 new messages