Intent to Remove: 3DES in TLS

[David Benjamin]

Primary eng (and PM) emails

davi...@chromium.org

Summary

Remove support for the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite in M93.

Motivation

TLS_RSA_WITH_3DES_EDE_CBC_SHA is a remnant of the SSL 2.0 and SSL 3.0 era. 3DES in TLS is vulnerable to the Sweet32 attack. Being a CBC cipher suite, it is also vulnerable to the Lucky Thirteen attack. The first replacement AES cipher suites were defined for TLS in RFC3268, published around 19 years ago, and we’ve had several iterations since.

The cipher suite is slow and CPU-intensive. On mobile, this translates to wasted battery. 3DES is, itself, expensive, and we have more efficient constructions than CBC. The mitigations needed to avoid the Lucky Thirteen attack add a further penalty. In total, on a fast desktop workstation, we can only process 32MB/s with 3DES, while AES-128-GCM with hardware acceleration hits 5.6GB/s. With all hardware and vector operations disabled, that workstation still hits 159M/s with AES-128-GCM and 480MB/s with ChaCha20-Poly1305.

Finally, many implementations of 3DES leak cache and timing side channels. This includes ours and OpenSSL’s, used in many servers. While it is possible to avoid this with a “constant-time” implementation, as we do for modern ciphers, this would even further increase 3DES’s CPU penalty. BearSSL reports a 3x hit for a constant-time implementation.

Interoperability and Compatibility Risk

Servers that only support TLS_RSA_WITH_3DES_EDE_CBC_SHA and no AES-based alternative will fail to connect. With the removal of TLS 1.0 and 1.1, 3DES usage has fallen away. See metrics below. Note TLS features are negotiated, so servers that support both modern cipher suites and 3DES will continue to work as before. There is no requirement to disable 3DES on the server, only enable replacements.

Edge: Supported, no signals on removal

Firefox: Supported, bug open and a previous attempt at removal four years ago

Safari: Supported, no signals on removal

Alternative implementation suggestion for web developers

Enable a modern cipher suite. We recommend enabling TLS 1.3 or, if not available, enabling TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with TLS 1.2. This should be a configuration-only change: all TLS 1.2 implementations we are aware of already implement modern cipher suites.

As a temporary workaround, enterprise administrators will be able to set the 3DESEnabled administrative policy to re-enable the cipher suites. This policy will also be available in Chrome 92 to help administrators test their networks ahead of the Chrome 93 change. It will be removed in Chrome 95, which will hit the stable channel in October 2021.

Usage information from UseCounter

Since Firefox’s previous attempt four years ago, 3DES usage has declined, and we added a fallback for more accurate measurements. The Net.SSL_CipherSuite histogram now reports 0.00% of TLS connections in Chrome stable use 3DES.

Entry on the feature dashboard

https://chromestatus.com/features/6678134168485888

[Mike West]

This is a good thing to do, and I'm happy to see the intent.

A few questions prior to LGTMing:

1. Regarding signals: we've coordinated with other vendors in the past on deprecations like these. Are you in contact with our colleagues regarding their timelines? If you haven't already, I'd suggest getting more official signals via the approaches documented in https://bit.ly/blink-signals, which could provide an opportunity for explicit alignment on timelines.

2. Have y'all thought about wiring ciphersuite changes up to devtools in some way to make it clear to developers who care to look that they're doing something that's going to stop working? Similarly, it would be helpful to give developers something of a roadmap: what's next on the list? Can we start warning about it on the security panel today?

3.  I'm happy to see the enterprise policy, as that seems like the most likely vector for unexpected usage. Thanks for thinking that through!

I don't think this particular deprecation requires a TAG review (based on some previous conversations, I somewhat expect them to punt such a question to the relevant group in the IETF). Is there some indication of broad support from that body for this change? It seems somewhat obvious to me that this is a good idea, but having a signal we could point to would be helpful.

Thanks!

-mike

[David Benjamin]

On Wed, Apr 28, 2021 at 3:02 AM Mike West <mk...@chromium.org> wrote:

This is a good thing to do, and I'm happy to see the intent.

A few questions prior to LGTMing:

1. Regarding signals: we've coordinated with other vendors in the past on deprecations like these. Are you in contact with our colleagues regarding their timelines? If you haven't already, I'd suggest getting more official signals via the approaches documented in https://bit.ly/blink-signals, which could provide an opportunity for explicit alignment on timelines.

https://github.com/mozilla/standards-positions/issues/516
https://lists.webkit.org/pipermail/webkit-dev/2021-April/031799.html

 

2. Have y'all thought about wiring ciphersuite changes up to devtools in some way to make it clear to developers who care to look that they're doing something that's going to stop working? Similarly, it would be helpful to give developers something of a roadmap: what's next on the list? Can we start warning about it on the security panel today?

Yup, those have been in place for a few years now. You can see this by opening the security panel on https://3des.badssl.com/. It also flags other bad configurations, such as https://cbc.badssl.com/, https://static-rsa.badssl.com/, and SHA-1 server signatures (which doesn't have a demo page but has corresponding text).

 

3.  I'm happy to see the enterprise policy, as that seems like the most likely vector for unexpected usage. Thanks for thinking that through!

I don't think this particular deprecation requires a TAG review (based on some previous conversations, I somewhat expect them to punt such a question to the relevant group in the IETF). Is there some indication of broad support from that body for this change? It seems somewhat obvious to me that this is a good idea, but having a signal we could point to would be helpful.

I don't think we have an explicit 3DES removal draft right now. The assumption for a while has been that 3DES was the price we paid to get rid of RC4. Happily, that turned out to be strongly correlated with TLS 1.0. Browser cipher suite profiles are also not explicitly specified and indeed we have slightly different ones at the edges. E.g. Safari has two more 3DES ciphers than we do.

But, to your broader question, there has been broad consensus for quite some time as to which cipher suites are recommended (ECDHE + AEAD) and which are legacy (everything else). After all, we did the DevTools UI above back in 2018 and have had a corresponding "secure/modern" vs "obsolete" marker in the UI for much much longer than that. Places you can see this:

RFC7525, which is a bit too timid in its recommendations (all CBC ciphers should be discouraged due to a flawed cryptographic construction) recommends against 3DES in the fourth bullet of section 4.1.

RFC8446 (TLS 1.3) dropped all 3DES cipher suites, among many others

RFC8447 introduced a Recommended column to the cipher suite registry and marked all 3DES ciphers, among others, as Recommended = N

RFC8996 cites an mandatory[*] 3DES cipher as part of why TLS 1.0 is problematic. Though that cipher also specifies DSS, so it has a couple counts against it.

And, as noted, there's the Sweet32 attack from 2016.

[*] TLS doesn't have a good history with "mandatory to implement" cipher suites and it's mostly fiction. That text is mostly ignored at this point, but old RFCs are immutable.

We've also generally been consistent in our messaging around other removals to encourage administrators to revisit their cipher suite configuration and skip straight to the "modern" (i.e. not 10+ years obsolete) configuration, rather than hopping from discouraged thing to marginally less discouraged thing.

https://security.googleblog.com/2018/10/modernizing-transport-security.html 

https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ

Also worth noting that anyone using 3DES has taken a performance penalty in Chromium for a year now.

[David Benjamin]

I think you may be misunderstanding the context of the DevTools UI. The Reporting API would not be appropriate for such far-future-facing things.

There are a large number of legacy TLS options which are known to be weak and long on the path towards removal. They are "deprecated" in the sense that we don't want sites to use them. However, they are not "deprecated" in the sense that we have a formal removal timeline. Old things take time to get flushed out, so we need to take care here. So we use a softer approach, the UI in the security panel to proactive nudge administrators towards better options. Using the Reporting API for, say, all CBC mode ciphers would be too noisy, and not appropriate, since a removal timeline has not yet been set.

Then, as serving software updates and administrators revisit their configurations, usage drops and we can set a removal date. (Keep in mind that TLS features behave very differently from web platform ones that this list is probably more accustomed to. It's a different set of people, different compatibility characteristics, etc.) That has since happened for 3DES, hence this email, step 3 here. With an actual removal date, louder warnings are reasonable.

Looks like the CountDeprecation machinery integrates into the Reporting API, so once we get there, that may just work. Although, that actually looks like a security problem here. If a cross-origin fetch triggers a deprecation notice, it would be a same-origin violation for the frame to learn the details. I'll need to look at that more closely and see whether this is yet another mismatch between how web platform APIs and TLS features work.

Regardless, 3DES is already at 0.00%, so this is about as low-risk as they come. Effectively, we already did this deprecation pass as part of the TLS 1.0/1.1 removal because they turned out to be correlated.

David

On Wed, Apr 28, 2021 at 3:53 PM Scott Helme <sc...@report-uri.com> wrote:

Hey everyone,

Is there any chance that this could send a Deprecation Report via the Reporting API along with such deprecations in the future? Regarding Mike's earlier comment, this is probably a better way to notify developers that want to know about such intents rather than hoping someone will catch it in Dev Tools!

Kind regards, 

 

Scott Helme | Founder 

E: sc...@report-uri.com 

W: report-uri.com 

  

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaAreYrLvFkgwf02e0Oz3U-agHXSivAATRVA1gxgOpkRRA%40mail.gmail.com.

[Scott Helme]

Hey everyone,

Is there any chance that this could send a Deprecation Report via the Reporting API along with such deprecations in the future? Regarding Mike's earlier comment, this is probably a better way to notify developers that want to know about such intents rather than hoping someone will catch it in Dev Tools!

Kind regards, 

 

Scott Helme | Founder 

E: sc...@report-uri.com 

W: report-uri.com 

  

On Wed, 28 Apr 2021 at 15:26, David Benjamin <davi...@chromium.org> wrote:

[Mike West]

LGTM1. The usage numbers are as low as they can go, and our friends at Mozilla are on board. Good luck with the removal!

For the future:

1.  I think the reporting API integration that Scott asks for is pretty reasonable to aim for when we deprecate the next cipher suite.

2.  Putting a die-die-die draft together with our friends in the IETF for posterity also seems reasonable. I'm happy to help with that.

Thanks!

-mike

[Daniel Bratell]

LGTM2 

(Enterprise policy may be a good thing but I think you can check that outside this decision)

/Daniel

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5fe8657a-f78e-47b5-b87f-ffdc33b65316n%40chromium.org.

[David Benjamin]

On Thu, Apr 29, 2021 at 2:57 PM Mike West <mk...@chromium.org> wrote:

LGTM1. The usage numbers are as low as they can go, and our friends at Mozilla are on board. Good luck with the removal!

For the future:

1.  I think the reporting API integration that Scott asks for is pretty reasonable to aim for when we deprecate the next cipher suite.

I'd have expected the reporting API to happen during the deprecation period (i.e. after we set a timeline but before the actual removal). Or are you suggesting we do it even before then? Flagging on every TLS thing we don't like would certainly be entertaining, but it'd probably be a problem. This email was setting the timeline.

Though I do want to look into the potential SOP bypass before sending out TLS-level deprecation reports. That may be something we want to address in the CountDeprecation API since I suspect anything keyed on the network would affect it. (My concern is that deprecation warnings are attached to the frame. That works for most APIs, but non-frame cross-origin subresources aren't quite fully under the frame's control.)

 

2.  Putting a die-die-die draft together with our friends in the IETF for posterity also seems reasonable. I'm happy to help with that.

Yeah, we should do one of those. I think 3DES mostly just slipped through since it wasn't as important as, say, draft-ietf-tls-md5-sha1-deprecate. But that one has a lot of messy confounding factors I need to work through in interpreting the metrics. Since 3DES is so low, I figure that warranted a priority swap.

[David Benjamin]

On Thu, Apr 29, 2021 at 3:16 PM Daniel Bratell <brat...@gmail.com> wrote:

LGTM2 

(Enterprise policy may be a good thing but I think you can check that outside this decision)

Yup. Already planned. :-)

[Yoav Weiss]

Alex Christensen over at webkit-dev saw that we're not publishing 3DES, and speculated that this is why we may see 0% usage.

I'm not sure it matters for removal (if we see 0%, we can remove support), but it might be interesting to clarify if this is indeed the case, as it may help other vendors to follow.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaCWqmhHJQdRuKG4aVUBXQq_8sHFKECjuTq6Cib-%3DyiniQ%40mail.gmail.com.

[David Benjamin]

Yup, just responded to that. It's an artifact of how we got a more accurate measurement, but it is certainly confusing. Here's what's going on:

https://lists.webkit.org/pipermail/webkit-dev/2021-April/031817.html

RC4 had similar effects when it was moved under fallback. We don't always move things under fallback (often the more naive upper-bound is low enough), but it's something we try when we have reason to believe the true impact is lower than the naive measurement.

[Yoav Weiss]

Got it! Thanks for following up! :)

[David Benjamin]

On Tue, Apr 27, 2021 at 5:26 PM David Benjamin <davi...@chromium.org> wrote:

Primary eng (and PM) emails

davi...@chromium.org

Summary

Remove support for the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite in M93.

Motivation

TLS_RSA_WITH_3DES_EDE_CBC_SHA is a remnant of the SSL 2.0 and SSL 3.0 era. 3DES in TLS is vulnerable to the Sweet32 attack. Being a CBC cipher suite, it is also vulnerable to the Lucky Thirteen attack. The first replacement AES cipher suites were defined for TLS in RFC3268, published around 19 years ago, and we’ve had several iterations since.

The cipher suite is slow and CPU-intensive. On mobile, this translates to wasted battery. 3DES is, itself, expensive, and we have more efficient constructions than CBC. The mitigations needed to avoid the Lucky Thirteen attack add a further penalty. In total, on a fast desktop workstation, we can only process 32MB/s with 3DES, while AES-128-GCM with hardware acceleration hits 5.6GB/s. With all hardware and vector operations disabled, that workstation still hits 159M/s with AES-128-GCM and 480MB/s with ChaCha20-Poly1305.

Finally, many implementations of 3DES leak cache and timing side channels. This includes ours and OpenSSL’s, used in many servers. While it is possible to avoid this with a “constant-time” implementation, as we do for modern ciphers, this would even further increase 3DES’s CPU penalty. BearSSL reports a 3x hit for a constant-time implementation.

Interoperability and Compatibility Risk

Servers that only support TLS_RSA_WITH_3DES_EDE_CBC_SHA and no AES-based alternative will fail to connect. With the removal of TLS 1.0 and 1.1, 3DES usage has fallen away. See metrics below. Note TLS features are negotiated, so servers that support both modern cipher suites and 3DES will continue to work as before. There is no requirement to disable 3DES on the server, only enable replacements.

Edge: Supported, no signals on removal

Firefox: Supported, bug open and a previous attempt at removal four years ago

Safari: Supported, no signals on removal

Alternative implementation suggestion for web developers

Enable a modern cipher suite. We recommend enabling TLS 1.3 or, if not available, enabling TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with TLS 1.2. This should be a configuration-only change: all TLS 1.2 implementations we are aware of already implement modern cipher suites.

As a temporary workaround, enterprise administrators will be able to set the 3DESEnabled administrative policy to re-enable the cipher suites.

A small update: pending reviewer feedback, we'll probably call this TripleDESEnabled instead of 3DESEnabled. C++ forbids variable names beginning with a digit. Policy names end up all over the place, so it seems best to avoid tempting fate. :-)