[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 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 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.


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

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/