Re: [TLS] Update on TLS 1.3 Middlebox Issues

Adam Langley <agl@imperialviolet.org> Sat, 07 October 2017 16:38 UTC

Return-Path: <alangley@gmail.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 D162D134CF1 for <tls@ietfa.amsl.com>; Sat, 7 Oct 2017 09:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pMwrqw0Nb-1U for <tls@ietfa.amsl.com>; Sat, 7 Oct 2017 09:38:26 -0700 (PDT)
Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 23B6D134CF0 for <tls@ietf.org>; Sat, 7 Oct 2017 09:38:26 -0700 (PDT)
Received: by mail-pf0-x242.google.com with SMTP id m28so19423684pfi.0 for <tls@ietf.org>; Sat, 07 Oct 2017 09:38:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=LvCQJVffhwEynUIiVToygkgMG0xZixBX0Lz3RAtUhXY=; b=by+2cALRc8oDwlMTwbTDe3UBOuauYcrWO48TAIqQ+Gs6omhNLH1B1cd+bfL9pfwust fpR9SPu+GHMC98C5laoD0pw+AipXhZO2gQDoboVFPCk3QnKSlPoz+IAyh1nbT381Nec3 Dv2XjZQ2qXQlilxSOeqgt2t7jt3/URHVJeHwwdst5lYTegEulwhtQFXNH8HhZIo4TOLs nFrpqOZR3GiWSP0ZUTIXx1SV5iGmNNjLtg9zhzGD3FtvnFSh1oSnc9hINDnbYs/IX3Zf DffQSzGWkg26J4gEOIJlB0ykKM8oT5wncSMY5hIGmYRvAlFfdCXM5wf55pNOGmJLCu7i JYlw==
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:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=LvCQJVffhwEynUIiVToygkgMG0xZixBX0Lz3RAtUhXY=; b=jSGdp4ipstMZ/groOsdnHcCyDVd7kU4wOufb05UKeIxKuJlxNTNAS/YdIl9+/0OSBv lN4CS6cETWifV2iGFcmRoBn9fnMiaPPW+k28XaZv6lk82ZYfsi5vUBILu6lmVwMnFSgo zaS0oWps79Ultn7CKCYcGR1lGLXmFfXeG5EkQUvI6tHlKyTzO6OJdiD8ka7fgG0CwCif hn0G8ltxcsqs9Wv38J89NJihbEbhSAbrJpjBwPAGYKEc8nJH0fB/ncuHOIzNEOqWaQbW G517YG6BbqEjEdUFecvGy01C6XV8nSy/XwRFXI5DrcOTMaHAFII8kazxI7fzhDagOvAl mL8Q==
X-Gm-Message-State: AMCzsaX5FLMwo9NVLOBsGhrv7OzmnAGVGc7Vm5TrPVxwQXPXfcYsQBex 8dglld7v4ECIMsBL2PTM0wEpH+QK0X/8dUz2AhdQfL3t
X-Google-Smtp-Source: AOwi7QCDncUWQIgtSVkPDHNSqlXbYAwj82rhYHL1aWCmYGm73snfQ8UnxO1CdmciTHm0DmFHMz7/WeG6AfAlVyk1Ud0=
X-Received: by 10.84.235.6 with SMTP id o6mr4965892plk.295.1507394305447; Sat, 07 Oct 2017 09:38:25 -0700 (PDT)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.100.165.194 with HTTP; Sat, 7 Oct 2017 09:38:24 -0700 (PDT)
In-Reply-To: <20171007091720.012fdb7b@pc1>
References: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com> <20171007091720.012fdb7b@pc1>
From: Adam Langley <agl@imperialviolet.org>
Date: Sat, 7 Oct 2017 09:38:24 -0700
X-Google-Sender-Auth: m9cK_D-uu85y32qdtOTV0r8qRvs
Message-ID: <CAMfhd9W-=-b4V0tX74k=thE9J2Vet-RH7a-XzkxLutRMT2_5Pg@mail.gmail.com>
To: =?UTF-8?Q?Hanno_B=C3=B6ck?= <hanno@hboeck.de>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/o7QXsNKqJP8QLsqM0MV-ndaYy3I>
Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues
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: Sat, 07 Oct 2017 16:38:28 -0000

On Sat, Oct 7, 2017 at 12:17 AM, Hanno Böck <hanno@hboeck.de>; wrote:
> Alternative proposal:
>
> 1. Identify the responsible vendors.
> 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh,
> it's your customers who don't update? Seems you don't have any
> reasonable update system. Call your customers, send some support staff
> to them. Fix this. Now."
> 3. Call for a boycott of the vendors who are not able to fix this.

In the past, Chrome has both steam-rollered over intolerance issues
and used "naming and shaming" when it appeared useful.

Naming and shaming can be an effective strategy when there is a small
percentage of aberrant actors, but that doesn't appear to be the case
here. It's not a single vendor, it's several, and we likely don't have
a complete list because it's very difficult to get
vendor/model/version information from the field. These issues vary
across devices, across firmware versions (for which the active range
is large), and across configurations (similarly large).

As for the steam-roller: while /we/ may understand the issues in
sufficient depth to know where the fault lies, the operating heuristic
in IT is that the last thing that changed is to blame. That makes
steam-rollering expensive. Sometimes we do it anyway, but the levels
of breakage measured for the current TLS 1.3 wire-format are too high
to be viable. There would have to be a fallback, and fallbacks are
terrible. We've only recently gotten out of the last lot of them and
should not do that again.

I understand the share the justifiable anger at companies that are
making profits by handicapping the internet that they depend on; we
are paying their externalities right now. But the problem here is too
widespread for either of the above strategies to be effective.

We're still testing, but it appears that a few,
security-inconsequential changes to TLS 1.3 make it significantly more
viable to deploy. That has got to be preferable to behaviours like
fallback, which is very security-consequential. This has taken time
because getting good exposure needs changes to both our frontends and
to Chrome Stable, which makes the iteration time long. We can iterate
much faster with local middleboxes (and we've bought several), but the
diversity of firmware versions and configurations means that we can't
get great testing coverage from that approach.

This looks, overwhelmingly, like the best path for TLS 1.3. For the
future, I think we need to ponder changes in the way that we build and
defend protocols. I think that GREASE
(https://tools.ietf.org/html/draft-ietf-tls-grease-00) demonstrates
the sort of change in thinking that is needed, but that we need to go
further.


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org