[TLS] Additional TLS 1.3 results from Chrome
David Benjamin <davidben@chromium.org> Mon, 18 December 2017 19:35 UTC
Return-Path: <davidben@google.com>
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 1B7FD12D862 for <tls@ietfa.amsl.com>; Mon, 18 Dec 2017 11:35:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.561
X-Spam-Level:
X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=amoPl2Q6; dkim=pass (1024-bit key) header.d=chromium.org header.b=jQkbK1r4
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 LqEoOsoE5y_g for <tls@ietfa.amsl.com>; Mon, 18 Dec 2017 11:35:34 -0800 (PST)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 7215112D853 for <tls@ietf.org>; Mon, 18 Dec 2017 11:35:34 -0800 (PST)
Received: by mail-qk0-x22d.google.com with SMTP id r184so12091059qke.8 for <tls@ietf.org>; Mon, 18 Dec 2017 11:35:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to :content-transfer-encoding; bh=+ZA7RHknDpaubGY2ox0ks9cxQGe1zSUuRW1i9E8bDao=; b=amoPl2Q61IUB1r0x3kmOxP7rhPUKDX+7zL3pZAqczPs/b1Qh4tCwyWpQn+vimIah/G 5LFEHr2FywNTw3h6B8UUyxKnov9YdzBzVf+tiJhwq71JHI5Y9hyd8tzgTUIRGr2wu5Ke brlG4qzoWl8ATn3XOLzTAQSNBEkaPG61yvJde6HmEbBbsyrq4O5YgZym+htHUzlKaoW3 SQhR3my3rFZ6XUCrD9DmizGaaddEIlDNa4ow4YWgwsBJpkWSDbe0YCzMsknTSS6o/UNw NLxR1mJ11vgIJEM5/U+NKym9CBITzuhii9dJLAPLl45zKATkJDgaI/XisyFQ3l/ygW/+ rr4g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:from:date:message-id:subject:to :content-transfer-encoding; bh=+ZA7RHknDpaubGY2ox0ks9cxQGe1zSUuRW1i9E8bDao=; b=jQkbK1r41oaJnrsUMZOqG5XDFuw0oZMVxsHTMhM9YFuZR2D7ohxv2V+bH6kYGSmh6c PhnxVgDirlUbQ9IePY23OTa8Z3kbESGqYvXikfmWRSVONKTo4rtfhBRl2zgnd2wWvIxq DbvHG9dmru5h7yasePBoDnkbU/OhsAIOxPcEo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-transfer-encoding; bh=+ZA7RHknDpaubGY2ox0ks9cxQGe1zSUuRW1i9E8bDao=; b=orKDOcCkVcyV8H6Hl/fMr8XM7CCvrJOawsM38T21kuz3GMjhyYQeq0XYHRNcMVuOFB kT013++GApdNjyh3Rtk6WV98jLKD2JuLAxUZd09liKu3bTsHJZnIpXE2VL9mlnJDwAJI T/FopEBA7SIY3rn92bLKrzIt+yr3LBYpANA0VfCZoZiVZZQPKXhxknRjqbplW81e+XCb vlBjXaZHClMtowKIz6BoZkKFVmhZi229sX6B90WJtniKXEy7G1AOza/Al+C4fBg24PMj 9P4kaEOeBNANY0XvTNon10wt1xiTaOmytjiwUB80YjKDg8Y9u3KiZ5p3pb9vVAoBxbnU jQwA==
X-Gm-Message-State: AKGB3mIssHpKjHdQ5y2h6cp47EwtaHsaZhLwcTVpj9dNJqMzkr31NBNp lEpPHWO5uKuQi4GyArEiiuBZFLgPgeCMEebIlPoFBr3Q0w==
X-Google-Smtp-Source: ACJfBovGhIqynhpQxY4CpnJpQZmUX3a7hiebH84MttGvh/A5HyqlcAQA7g+Yu88FUcAC2a3RN8jShsWe47L2XZTpqVo=
X-Received: by 10.55.181.66 with SMTP id e63mr1284938qkf.130.1513625732997; Mon, 18 Dec 2017 11:35:32 -0800 (PST)
MIME-Version: 1.0
Sender: davidben@google.com
Received: by 10.237.57.10 with HTTP; Mon, 18 Dec 2017 11:35:12 -0800 (PST)
From: David Benjamin <davidben@chromium.org>
Date: Mon, 18 Dec 2017 14:35:12 -0500
X-Google-Sender-Auth: M8Y0SaMjUs7OwyoCYxNJMfCXAbk
Message-ID: <CAF8qwaA4su2j-Lh9XRcLbT_Tysg9H24ys=TCC=Rd1bvrFNds7A@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/i9blmvG2BEPf1s1OJkenHknRw9c>
Subject: [TLS] Additional TLS 1.3 results from Chrome
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 18 Dec 2017 19:35:36 -0000
Dear all, The recent release of Google Chrome 63 enabled (effectively) TLS 1.3 draft 22 for 95% of stable channel users who updated. (Our previous results were on our beta channel.) While, in the past, we have demurred[1] from providing details about problematic products we now plan to alter that stance. It is late in the game for TLS 1.3 and we have likely exhausted the scope of wire-format tricks to improve deployment viability (although there is one more helpful tweak below). Since other vendors will also be seriously deploying TLS 1.3 soon, we want to share all that we have learned from Chrome. We note, however, that even being included in a stable release of Google Chrome doesn’t provide a full picture of any issues. For example, enterprise customers may choose not to release any new versions of software into their organisations in the run-up to Christmas and New Year’s. Also, we are aware that only a tiny fraction of issues result in user reports. This experiment in Chrome 63 will end on 2017-12-19, hopefully ensuring a quiet Christmas. BSAFE The web interface on some Canon printers breaks with 1.3-capable ClientHello messages. We have purchased one and confirmed this with a PIXMA MX492. User reports suggest that it also affects PIXMA MG3650 and MX495 models. It potentially affects a wide range of Canon printers. These printers use the RSA BSAFE library to implement TLS and this library implements the extended_random extension and assigns it number 40. This collides with the key_share extension and causes 1.3-capable handshakes to fail. We understand that this has been fixed in BSAFE ≥ 4.1, but older versions still exist in the world. Canon is aware of this and is planning on issuing firmware updates, although the uptake of firmware for printers is typically poor. However, since extension numbers are essentially infinite, this WG may consider renumbering key_share to avoid the issue. Dymo (the label-printer manufacturer) is experiencing a similar[2] issue with some of their software. We have not been able to reproduce but one guess is that they are also using BSAFE. (Lastly, we note that in the paper "On the Practical Exploitability of Dual EC in TLS Implementations", the authors remarked that they had no evidence that a version of BSAFE with extended_random support ever shipped. TLS 1.3 appears to have tripped over it.) Cisco Firepower After receiving a report of issues with a Cisco “Firepower” device we purchased one to try and reproduce the issue. We found that Firepower middleboxes in "Decrypt - Resign" mode terminate TLS connections, but do not send a compliant ClientHello: They modify the original ClientHello to remove unknown ciphersuites, EMS, and NPN, but incorrectly forward most other fields from the original ClientHello, including unknown extensions (supported_versions and key_shares), and the client random. This breaks TLS 1.3 servers. Additionally, these devices forward the server random rather than generating their own (which will break when deploying the TLS 1.3 anti-downgrade feature), and forward unknown signature algorithms (which will break when deploying, e.g., Ed25519). Disabling "Decrypt - Resign" mode appears to work around this issue. To fix this mode, these devices will need to stop forwarding unknown extensions and generate their own random values. We have provided Cisco with this information. Avast Antivirus We have received one report that Avast’s HTTPS scanning feature breaks connections that negotiate TLS 1.3. The user reported that disabling HTTPS scanning solved the issue. We were not able to reproduce so this might only occur with older versions of Avast. [1] https://www.ietf.org/mail-archive/web/tls/current/msg24535.html [2] http://developers.dymo.com/2017/12/12/err_ssl_version_interference-in-chrome-63-using-the-js-sdk/
- Re: [TLS] Additional TLS 1.3 results from Chrome Tim Hollebeek
- [TLS] Additional TLS 1.3 results from Chrome David Benjamin
- Re: [TLS] Additional TLS 1.3 results from Chrome Eric Rescorla
- Re: [TLS] Additional TLS 1.3 results from Chrome Tanja Lange
- Re: [TLS] Additional TLS 1.3 results from Chrome Salz, Rich
- Re: [TLS] Additional TLS 1.3 results from Chrome Stephen Farrell
- Re: [TLS] Additional TLS 1.3 results from Chrome Salz, Rich
- Re: [TLS] Additional TLS 1.3 results from Chrome Stephen Farrell
- Re: [TLS] Additional TLS 1.3 results from Chrome Adam Langley
- Re: [TLS] Additional TLS 1.3 results from Chrome Eric Rescorla
- Re: [TLS] Additional TLS 1.3 results from Chrome Ilari Liusvaara
- Re: [TLS] Additional TLS 1.3 results from Chrome Eric Rescorla
- Re: [TLS] Additional TLS 1.3 results from Chrome David Wong