Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794A0130DC8 for ; 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-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhZ19oF07bDZ for ; 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 ; Fri, 12 Oct 2018 12:49:11 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id v68-v6so8377450qka.2 for ; 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 Date: Fri, 12 Oct 2018 14:48:57 -0500 Message-ID: To: "" Cc: "svaldez@chromium.org" , Adam Langley Content-Type: multipart/alternative; boundary="0000000000008c27db05780d61ad" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 19:49:14 -0000 --0000000000008c27db05780d61ad Content-Type: text/plain; charset="UTF-8" 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 . 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 in the ServerHello random field that could not be deployed in draft versions. This signal strengthens 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 prior versions 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 . 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 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 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 --0000000000008c27db05780d61ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

The upcoming relea= se 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 l= earned about some deployment issues we would like to share with the communi= ty.

First, we are aware of some intolerance to the= final TLS 1.3 code point, 0x0304. Prerelease versions of OpenSSL 1.1.1, na= mely -pre6 and earlier, implemented the draft versions of TLS 1.3 incorrectly. Althou= gh the draft versions used separate 0x7fxx code points for forward-compatib= ility, OpenSSL incorrectly also interpreted 0x0304 as a draft version. Thes= e servers will respond to a TLS 1.3 ClientHello with a draft version, rathe= r than TLS 1.2, and fail to interoperate.

Early ad= opters of OpenSSL should upgrade to the final 1.1.1 release. Those that can= not upgrade quickly should disable the draft TLS 1.3 in configuration. We d= o 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 <= a href=3D"https://tools.ietf.org/html/rfc8446#section-4.1.3">downgrade sign= al in the ServerHello random field that could not be deployed in draft = versions. This signal strengthens TLS 1.3 connections while = remaining fully backwards compatible with TLS 1.2 and earlier. Unfortunatel= y, despite the solid compatibility story, we are observing deployment issue= s.

We believe these are caused by non-compliant TL= S-terminating proxies which, rather than generating their own random values= , copy the value from the origin server. This behavior is incorrect for all prior versions of TL= S. When such a proxy terminates a connection between a TLS 1.3 client and s= erver, the resulting pair of TLS 1.2 connections appear as a downgrade and = are rejected.

We are aware of two vendors whose pr= oducts have this bug: Cisco and Palo Alto Networks, although there may be m= ore. We reported the issue to Cisco in December 2017. They released the fix= this past August and have published an advisor= y. Palo Alto Networks recently discovered the issue on their devices an= d 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 valu= es 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 suc= h flaws as security issues, and not mere functional flaws. Additionally, ve= ndors should note the Protocol Invariants 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 t= emporarily disabled. While we still have downgrade protection via the Finis= hed 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 dis= abling the False Start = optimization on connections with the downgrade signal, as False Start skips= the Finished check. Note this effectively disables the optimization on aff= ected middleboxes. Vendors should fix the underlying ServerHello random fla= w 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 leav= e the signal enabled on the server. The False-Start-only enforcement is val= uable, and the server signal aids client measurement. Compatibility issues = can be mitigated instead on the client.

David
--0000000000008c27db05780d61ad--