[TLS] TLS 1.3 updates from Chrome

David Benjamin <davidben@chromium.org> Fri, 12 October 2018 19:49 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 794A0130DC8 for <tls@ietfa.amsl.com>; Fri, 12 Oct 2018 12:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.25
X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qhZ19oF07bDZ for <tls@ietfa.amsl.com>; Fri, 12 Oct 2018 12:49:11 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7181286E3 for <tls@ietf.org>; Fri, 12 Oct 2018 12:49:11 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id v68-v6so8377450qka.2 for <tls@ietf.org>; Fri, 12 Oct 2018 12:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=sgJlHeLYmKwmGKJTFbE/3pGAtYOn/tOKPDGb3rpbe6g=; b=At+3Jhuz/1QdVtqA+NElVgkPqoEHlsKGq+bJkdOKKVI2dPjZgjPpNpvugP/ggZ/Yai kHLZWzc3glx1m0UyhTuctq2a1BpeBmISZQQgT/kaRKseO6AO+YJxyX0pLdPZTnIvFah/ ySTH8o0x3SNWeVq49gUGk6WObOmcYAqEOkSQk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=sgJlHeLYmKwmGKJTFbE/3pGAtYOn/tOKPDGb3rpbe6g=; b=RLqlAJggfI67qBT7Qs5Gr8wmmhFBiGeTyezlEMb8D2G4fagTo8oqZIvzUcXz7sme+k P2MYHRqSALJPZkabEm4KmT4v4y2lqIuQWWMlys+j567tqbjO7fmo2ADdCNVbJtTF6d1T 9eP+VyhgZCdpawU9siZw7QNZVH0ymayT//hOD7SIbkdEh0gePwUko6azvUF1QaGbBwYB VVvsKyFJrTea3Z75hI0nje7jEQ2yHhVEM8PVHYW6AQQYDaRIe854lSNn2tfRdRF3zvzk 9l1EcqXrUDY30ZH8Asy0fAPUFfYAVupYyMxlCbZgRQgF37VMQY8pkIn+LGkFXZnjKqj2 59Rg==
X-Gm-Message-State: ABuFfoi90+1lJGH7uH011evQW+ZS2lLT/g2VxUeLcUjbH8xFF4NOpeaI MbUH2z0y4qeC6vNtjQwgLh7WD96NFiIHoDP7zcrRIUGxIQ==
X-Google-Smtp-Source: ACcGV62u7RgcB+hF0uJzifVA7+uTRHzWlqH7G7ioPk+r+n0D1+Y85ipXbfhKR3OydMbYlvfEvDxlu61wDMVL0y9Ud7s=
X-Received: by 2002:a37:4ece:: with SMTP id c197-v6mr7033875qkb.320.1539373750002; Fri, 12 Oct 2018 12:49:10 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Fri, 12 Oct 2018 14:48:57 -0500
Message-ID: <CAF8qwaD4kdmSgesPbT0U5aFRM9Z_pV_i6b0AYwMUHqS-Fza6mA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Cc: "svaldez@chromium.org" <svaldez@chromium.org>, Adam Langley <agl@chromium.org>
Content-Type: multipart/alternative; boundary="0000000000008c27db05780d61ad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PLtOD4kROZFfNtPKzSoMyIUOzuE>
Subject: [TLS] TLS 1.3 updates from Chrome
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Oct 2018 19:49:14 -0000

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
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-> prior
<https://tools.ietf.org/html/rfc4346#section-> versions
<https://tools.ietf.org/html/rfc2246#section-> 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

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
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.