Intent to Implement and Ship: TLS 1.3

[David Benjamin]

Contact emails

davi...@chromium.org, sva...@chromium.org

Design doc/Spec

https://tools.ietf.org/html/rfc8446

(TAG review N/A. This is a network protocol under the IETF, not a web platform API under the W3C.)

Summary

Ship TLS 1.3 in 1-RTT mode. We had previously shipped draft versions to Chrome. The specification is now done! We will ship the final RFC and unship the draft versions.

Motivation

TLS 1.3 is a major revision of the TLS protocol. It has a new handshake with a simpler, more modern design and improved security. Resumption is now forward-secure and more of the handshake is encrypted. It also enables a new feature, 0-RTT, inspired by the same feature in QUIC, which allows application data to be sent in the first round-trip. (This Intent is only for the 1-RTT mode. We will ship 0-RTT separately.)

Risks

Interoperability and Compatibility

We have spent the past two years working on interoperability and compatibility for TLS 1.3. We successfully shipped a draft version of the protocol to stable Chrome in March of this year. The final version of TLS is the same except that it uses the final version codepoint and one detail below. See our previous Intent thread for a more in-depth discussion. The update here is that it worked.

There is one detail in the final RFC that could not be tested in draft versions. TLS 1.3 adds an anti-downgrade security measure, based on the server random field. This strengthens the existing anti-downgrade protections in the protocol. There is no breakage risk for users connecting to servers directly, nor for users behind a TLS-terminating middlebox (such as an antivirus or some enterprise middleware products), provided the middlebox correctly implemented prior TLS versions.

However, we are aware of an issue with Cisco Firepower firewalls. In some configurations, these firewalls copy server randoms when terminating TLS, rather than generating fresh values as required by TLS 1.0 through 1.2. Users behind such firewalls will experience connection failures with TLS-1.3-capable servers. We informed Cisco of this in December of last year. They plan on releasing a fix next week. We will implement a dedicated error code for this case in Chrome to aid diagnosis.

As before, we will be controlling the deployment using Chrome’s field trials mechanism, so we can react to unforeseen issues. We will additionally condition the anti-downgrade feature on a separate field trial, so it may be independently temporarily disabled in case of problems with non-compliant middleboxes.

Edge: Public support

Firefox: In development

Safari: In development

Web developers: OpenSSL, Akamai, Cloudflare, Facebook

Ergonomics

TLS 1.3 is a network protocol, so it is largely abstracted away from the web platform. It does enable 0-RTT which is a bit more developer-visible, but that will be shipped separately.

Activation

This is a network protocol and thus inherently requires server software changes. It should become available to site owners as server software and hosting providers ship the update.

Debuggability

The security panel reports which TLS version was used.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

No. See here for issues with using web-platform-tests for this right now. Instead, we have very thorough test suite in BoringSSL. Other stacks have even had some success in using it.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5934924745932800

Requesting approval to ship?

Yes

[Yoav Weiss]

LGTM1 using the proposed field trial plan

On Sat, Aug 11, 2018 at 3:03 AM David Benjamin <davi...@chromium.org> wrote:

Contact emails

davi...@chromium.org, sva...@chromium.org

Design doc/Spec

https://tools.ietf.org/html/rfc8446

(TAG review N/A. This is a network protocol under the IETF, not a web platform API under the W3C.)

Summary

Ship TLS 1.3 in 1-RTT mode. We had previously shipped draft versions to Chrome. The specification is now done! We will ship the final RFC and unship the draft versions.

Motivation

TLS 1.3 is a major revision of the TLS protocol. It has a new handshake with a simpler, more modern design and improved security. Resumption is now forward-secure and more of the handshake is encrypted. It also enables a new feature, 0-RTT, inspired by the same feature in QUIC, which allows application data to be sent in the first round-trip. (This Intent is only for the 1-RTT mode. We will ship 0-RTT separately.)

Risks

Interoperability and Compatibility

We have spent the past two years working on interoperability and compatibility for TLS 1.3. We successfully shipped a draft version of the protocol to stable Chrome in March of this year. The final version of TLS is the same except that it uses the final version codepoint and one detail below. See our previous Intent thread for a more in-depth discussion. The update here is that it worked.

There is one detail in the final RFC that could not be tested in draft versions. TLS 1.3 adds an anti-downgrade security measure, based on the server random field. This strengthens the existing anti-downgrade protections in the protocol. There is no breakage risk for users connecting to servers directly, nor for users behind a TLS-terminating middlebox (such as an antivirus or some enterprise middleware products), provided the middlebox correctly implemented prior TLS versions.

However, we are aware of an issue with Cisco Firepower firewalls. In some configurations, these firewalls copy server randoms when terminating TLS, rather than generating fresh values as required by TLS 1.0 through 1.2. Users behind such firewalls will experience connection failures with TLS-1.3-capable servers. We informed Cisco of this in December of last year. They plan on releasing a fix next week. We will implement a dedicated error code for this case in Chrome to aid diagnosis.

*sigh*

Do you know how fast Cisco will deploy that fix? Or is it on their users to update their software once a fix is released? From their documentation it seems to be the latter... (and to quote the manual "can be a complex process", so likely to take a while before people will actually deploy it)

Do we have any notion of how much of the user population will be affected by this? Will the affected end-users mostly be enterprise users? (which can theoretically complain to their IT, and eventually have them upgrade the firewall)

 

As before, we will be controlling the deployment using Chrome’s field trials mechanism, so we can react to unforeseen issues. We will additionally condition the anti-downgrade feature on a separate field trial, so it may be independently temporarily disabled in case of problems with non-compliant middleboxes.

Being able to separately turn off the anti-downgrade feature sounds like a good idea, in case we will find that it is not currently deployable.

 

Edge: Public support

Firefox: In development

Safari: In development

Web developers: OpenSSL, Akamai, Cloudflare, Facebook

Ergonomics

TLS 1.3 is a network protocol, so it is largely abstracted away from the web platform. It does enable 0-RTT which is a bit more developer-visible, but that will be shipped separately.

Activation

This is a network protocol and thus inherently requires server software changes. It should become available to site owners as server software and hosting providers ship the update.

Debuggability

The security panel reports which TLS version was used.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

No. See here for issues with using web-platform-tests for this right now. Instead, we have very thorough test suite in BoringSSL. Other stacks have even had some success in using it.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5934924745932800

Requesting approval to ship?

Yes

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAF8qwaDWUyinYxDcjTb-64DcKMZofhaEg-xE-7xG5bC2j8STUQ%40mail.gmail.com.

[Steven Valdez]

On Mon, Aug 13, 2018 at 3:50 AM Yoav Weiss <yo...@yoav.ws> wrote:

LGTM1 using the proposed field trial plan

On Sat, Aug 11, 2018 at 3:03 AM David Benjamin <davi...@chromium.org> wrote:

Contact emails

davi...@chromium.org, sva...@chromium.org

Design doc/Spec

https://tools.ietf.org/html/rfc8446

(TAG review N/A. This is a network protocol under the IETF, not a web platform API under the W3C.)

Summary

Ship TLS 1.3 in 1-RTT mode. We had previously shipped draft versions to Chrome. The specification is now done! We will ship the final RFC and unship the draft versions.

Motivation

TLS 1.3 is a major revision of the TLS protocol. It has a new handshake with a simpler, more modern design and improved security. Resumption is now forward-secure and more of the handshake is encrypted. It also enables a new feature, 0-RTT, inspired by the same feature in QUIC, which allows application data to be sent in the first round-trip. (This Intent is only for the 1-RTT mode. We will ship 0-RTT separately.)

Risks

Interoperability and Compatibility

We have spent the past two years working on interoperability and compatibility for TLS 1.3. We successfully shipped a draft version of the protocol to stable Chrome in March of this year. The final version of TLS is the same except that it uses the final version codepoint and one detail below. See our previous Intent thread for a more in-depth discussion. The update here is that it worked.

There is one detail in the final RFC that could not be tested in draft versions. TLS 1.3 adds an anti-downgrade security measure, based on the server random field. This strengthens the existing anti-downgrade protections in the protocol. There is no breakage risk for users connecting to servers directly, nor for users behind a TLS-terminating middlebox (such as an antivirus or some enterprise middleware products), provided the middlebox correctly implemented prior TLS versions.

However, we are aware of an issue with Cisco Firepower firewalls. In some configurations, these firewalls copy server randoms when terminating TLS, rather than generating fresh values as required by TLS 1.0 through 1.2. Users behind such firewalls will experience connection failures with TLS-1.3-capable servers. We informed Cisco of this in December of last year. They plan on releasing a fix next week. We will implement a dedicated error code for this case in Chrome to aid diagnosis.

*sigh*

Do you know how fast Cisco will deploy that fix? Or is it on their users to update their software once a fix is released? From their documentation it seems to be the latter... (and to quote the manual "can be a complex process", so likely to take a while before people will actually deploy it)

Do we have any notion of how much of the user population will be affected by this? Will the affected end-users mostly be enterprise users? (which can theoretically complain to their IT, and eventually have them upgrade the firewall)

 I believe that most users will have to pull in the latest maintenance release manually in order to get the fix, I don't think this will get automatically deployed. From previous user reports, almost all the affected users are in enterprise settings, so will at least have a channel to complain to get the firewall upgraded. This shouldn't affect non-enterprise users, since Firepower firewalls with these features aren't really seen there.

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/CACj%3DBEg0NLW3fHZxr8qhmB%3Dngsk3DHW0ndg%3D1CFYwZAnrBiUdg%40mail.gmail.com.

--

Steven Valdez |

Chrome Networking |

sva...@google.com |

210-692-4742

[David Benjamin]

On Mon, Aug 13, 2018 at 1:13 PM <tiala...@gmail.com> wrote:

On Monday, 13 August 2018 08:50:16 UTC+1, Yoav Weiss wrote:

Being able to separately turn off the anti-downgrade feature sounds like a good idea, in case we will find that it is not currently deployable.

This needs to be very much a last resort. Most TLS 1.3 benefits against an active attacker don't accrue if they can just force a downgrade to TLS 1.2 or earlier. So if browsers have to "turn off" anti-downgrade much of the TLS 1.3 work was wasted since we know there are active attackers out there who'll just force a downgrade.

Please try to hold your nerve guys, as with SHA-1 if it's tough to stand alone try to get the other browser vendors to at least _announce_ they're going to have anti-downgrade so that it's a unified front. If that's intractable, maybe do anti-downgrade by default but with a Group Policy override so that the inevitable stragglers using unpatched Cisco "security" devices have a way to sidestep for a few months while they get their act together. The eventual pay off for having working anti-downgrade is that your story when TLS 1.2 looks wobbly becomes less all-or-nothing, because TLS 1.3 servers can't be downgraded.

Thanks for the feedback! Fortunately, the situation is less dire than I think you may have read it.

You are correct on the importance of downgrade protection in TLS. Without it, security improvements in new versions of TLS are meaningless. Indeed, TLS 1.3 would have shipped two years ago were it not for our insistence that we be able to ship it with downgrade protection. (As is the standard for other TLS changes.)

Fortunately, turning off this anti-downgrade signal would not leave TLS 1.3 unprotected. TLS already inherits the existing downgrade protection mechanism based on the Finished check. We spent a lot of effort so that TLS 1.3 could be deployed without the old insecure fallback dance we'd worked so hard to fix. It cost a delay, but our draft version deployments showed the work paid off. TLS 1.3 is deployable without an insecure fallback!

Still, the Finished check is not ideal. TLS 1.2's ServerKeyExchange signs only the randoms, rather than the entire transcript, so we are dependent on more of the TLS 1.2 handshake for downgrade protection. This mistake elevated FREAK and LogJam from academic curiosities to practical attacks. We cannot retroactively change TLS 1.2, nor will we have any hope of removing it for a very very long time, so TLS 1.3 adds the additional server-random signal. This is basically a hack around one of the few places TLS 1.2 did think to sign. (Note, however, that it too reduces to the Finished hash verification in the presence of RSA decryption cipher suites. Sadly, those are also not practical to remove right now. Many sites rely on them, despite their many known flaws.)

Thus, yes, this server-random signal is an important part of TLS 1.3 and we do intend to deploy it. However, the reality is that Cisco Firepower devices failed to correctly implement TLS 1.2, and did so in a way that breaks this. It is a shame that the fix was not released months ago when we reported the issue, but so it goes. I'm hopeful that folks can update their broken devices and we can get this change to stick.

But things may always go wrong. Maybe there are more vendors to contact. Maybe the impact is larger than expected. The separate field trial control is so we can keep the rest of TLS 1.3 (including Finished-based downgrade protection) enabled while we measure things and evaluate options. It is not intended as a permanent state.

(Come to think of it, if enforcement is disabled, we should still have the signal disable False Start since that bypasses the Finished check. That avoids one of the Finished check's problems and won't break things. It's just a missed optimization on these broken devices.)

Hopefully that makes our thinking clearer.

David

[tiala...@gmail.com]

On Monday, 13 August 2018 08:50:16 UTC+1, Yoav Weiss wrote:

Being able to separately turn off the anti-downgrade feature sounds like a good idea, in case we will find that it is not currently deployable.

[David Benjamin]

(Friendly ping to Blink owners.)

[Chris Harrelson]

LGTM2

[Philip Jägenstedt]

LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BN6QZvsMrD0Q9tqpvqx-FcbVPfoeDMzSuUPC7ZprxU9jUr4iA%40mail.gmail.com.