[TLS] TLS 1.3 updates from Chrome

[David Benjamin <[e-mail]>]

Dear all,

The upcoming release of Google Chrome 70 is expected to enable the final
version of TLS 1.3. As the release has progressed through our early release
channels, we have learned about some deployment issues we would like to
share with the community.

First, we are aware of some intolerance to the final TLS 1.3 code point,
0x0304. Prerelease versions of OpenSSL 1.1.1, namely -pre6 and earlier,
implemented the draft versions of TLS 1.3 incorrectly
<https://github.com/openssl/openssl/issues/7315>. Although the draft
versions used separate 0x7fxx code points for forward-compatibility,
OpenSSL incorrectly also interpreted 0x0304 as a draft version. These
servers will respond to a TLS 1.3 ClientHello with a draft version, rather
than TLS 1.2, and fail to interoperate.

Early adopters of OpenSSL should upgrade to the final 1.1.1 release. Those
that cannot upgrade quickly should disable the draft TLS 1.3 in
configuration. We do not believe this problem to be widespread and do not
intend to delay TLS 1.3 in Chrome for it.

Second, TLS 1.3 includes a downgrade signal
<https://tools.ietf.org/html/rfc8446#section-4.1.3> in the ServerHello
random field that could not be deployed in draft versions. This signal
strengthens
<https://crypto.iacr.org/2018/affevents/cwtls/medias/Karthik_Bhargavan.pdf>
TLS 1.3 connections while remaining fully backwards compatible with TLS 1.2
and earlier. Unfortunately, despite the solid compatibility story, we are
observing deployment issues.

We believe these are caused by non-compliant TLS-terminating proxies which,
rather than generating their own random values, copy the value from the
origin server. This behavior is incorrect for all
<https://tools.ietf.org/html/rfc5246#section-7.4.1.3> prior
<https://tools.ietf.org/html/rfc4346#section-7.4.1.3> versions
<https://tools.ietf.org/html/rfc2246#section-7.4.1.3> of TLS. When such a
proxy terminates a connection between a TLS 1.3 client and server, the
resulting pair of TLS 1.2 connections appear as a downgrade and are
rejected.

We are aware of two vendors whose products have this bug: Cisco and Palo
Alto Networks, although there may be more. We reported the issue to Cisco
in December 2017. They released the fix this past August and have published
an advisory
<https://www.cisco.com/c/dam/en/us/td/docs/security/firepower/SA/SW_Advisory_CSCvj93913.pdf>.
Palo Alto Networks recently discovered the issue on their devices and are
planning to release PAN-OS 8.1.4, PAN-OS 8.0.14, and PAN-OS 7.1.21 to fix
this, tentatively by Nov 30th.

As random values in security protocols are there for a reason and assumed
to be random by all security analysis, we would advise that all affected
vendors treat such flaws as security issues, and not mere functional flaws.
Additionally, vendors should note the Protocol Invariants
<https://tools.ietf.org/html/rfc8446#section-9.3> section of RFC 8446,
which points out areas historically dense in errors.

Due to the above, we will sadly be shipping TLS 1.3 in Chrome 70 with the
server-random check temporarily disabled. While we still have downgrade
protection via the Finished check, we consider this additional protection
an important part of TLS 1.3 and plan on re-enabling it in the near future.
Additionally, we are disabling the False Start
<https://tools.ietf.org/html/rfc7918> optimization on connections with the
downgrade signal, as False Start skips the Finished check. Note this
effectively disables the optimization on affected middleboxes. Vendors
should fix the underlying ServerHello random flaw to recover performance.

We would recommend other clients considering similar measures to also
disable False Start when the signal is present. To that end, we ask that
TLS 1.3 server deployments leave the signal enabled on the server. The
False-Start-only enforcement is valuable, and the server signal aids client
measurement. Compatibility issues can be mitigated instead on the client.

David