Re: [TLS] Update on TLS 1.3 Middlebox Issues

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 07 October 2017 17:28 UTC

Return-Path: <ilariliusvaara@welho.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 978E6134A9F for <tls@ietfa.amsl.com>; Sat, 7 Oct 2017 10:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 TbDnq2D-Pvtd for <tls@ietfa.amsl.com>; Sat, 7 Oct 2017 10:28:30 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CA3134AA1 for <tls@ietf.org>; Sat, 7 Oct 2017 10:28:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 076C44189C; Sat, 7 Oct 2017 20:28:27 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id sGi5dhfKqzAt; Sat, 7 Oct 2017 20:28:26 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2C12F21C; Sat, 7 Oct 2017 20:28:22 +0300 (EEST)
Date: Sat, 7 Oct 2017 20:28:22 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Adam Langley <agl@imperialviolet.org>
Cc: Hanno =?utf-8?B?QsO2Y2s=?= <hanno@hboeck.de>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20171007172822.6plag25tzae6wzi4@LK-Perkele-VII>
References: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com> <20171007091720.012fdb7b@pc1> <CAMfhd9W-=-b4V0tX74k=thE9J2Vet-RH7a-XzkxLutRMT2_5Pg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMfhd9W-=-b4V0tX74k=thE9J2Vet-RH7a-XzkxLutRMT2_5Pg@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fM42qprjIuLQfXFx9nnvjXNQE8s>
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 17:28:32 -0000

On Sat, Oct 07, 2017 at 09:38:24AM -0700, Adam Langley wrote:
> 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.

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

Yes, and with local testing, one can't get the relative importances
right, only to guide what to test on field.

And even in field tests, there is issue of survivorship bias. I think
that is the cause for seeming conflicts between the results.

And even if the changes might not be directly consequential to
security, the changes to get through some more annoying middleboxes
might be quite annoying to implement.

E.g. there probably are several different middeboxes that have a
configuration that actually checks that the handshake looks valid,
which includes checks for things like ChangeCipherSpec being
present in both directions, even for resumption; while the non-
resumption mode might even verify the authentication signatures in
the handshake and not letting server send non-handshake messages
before sending its 2nd flight. Ugh, getting around those would be
pretty nasty.



-Ilari