Re: [TLS] Update on TLS 1.3 Middlebox Issues

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 08 October 2017 08:09 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 538D2134DF1 for <tls@ietfa.amsl.com>; Sun, 8 Oct 2017 01:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 6dfnCmiYC0cT for <tls@ietfa.amsl.com>; Sun, 8 Oct 2017 01:09:30 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC49C134DA9 for <tls@ietf.org>; Sun, 8 Oct 2017 01:09:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 666B6B518C; Sun, 8 Oct 2017 11:09:26 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id GIRtoYq1GlPn; Sun, 8 Oct 2017 11:09:25 +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-smtp3.welho.com (Postfix) with ESMTPSA id 82FF32313; Sun, 8 Oct 2017 11:09:22 +0300 (EEST)
Date: Sun, 8 Oct 2017 11:09:22 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Jeffrey Walton <noloader@gmail.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20171008080922.pqhnj6rw26vo42sy@LK-Perkele-VII>
References: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com> <EAD84CE1-41A9-40FE-B882-18F077FFD691@akamai.com> <17791E16-1E12-4E8E-A098-31E961C2B2CB@gmail.com> <CAOjisRx9rwtbwBOTB+PegrKim2Q3bDmwbZi6KAu0aFMEaYSxRw@mail.gmail.com> <A6896A64-A0B3-409A-ABC2-1EF1D7DD0E7D@akamai.com> <CAL02cgQc2UriU7EZzpYpdxMrj15fDrfsD3adS0TeqhTe8ZEcBA@mail.gmail.com> <CABcZeBP9sqG6sHEdN1hLj4_gT7qQM9vAnhGussrUwkaFO+gciA@mail.gmail.com> <C7396C83-9F02-4BF8-B490-4EA8DB9798B1@akamai.com> <CAH8yC8=cPGZy20G=mw=5qZ4Y0FmYXtLq0v_FXoVxsFFWpu18Mg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAH8yC8=cPGZy20G=mw=5qZ4Y0FmYXtLq0v_FXoVxsFFWpu18Mg@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tJAQjHJY-d1-rLSqVl5kIfI-V0M>
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: Sun, 08 Oct 2017 08:09:32 -0000

On Sat, Oct 07, 2017 at 11:33:33AM -0400, Jeffrey Walton wrote:
> On Sat, Oct 7, 2017 at 11:25 AM, Salz, Rich <rsalz@akamai.com>; wrote:
> >
> >
> >> I suggest we not have this debate now. We'll have a lot more data towards
> >> the end of the month and we can have an informed discussion then.
> >
> 
> > That is what I am asking for.  More information so that the entire WG can
> > make an informed decision.  And I was only laying out an option that does
> > not seem to have been considered before.
> 
> The group (or the IETF) might also consider a policy to answer Ilari
> Liusvaara's question, "What you think is acceptable failure rate?"
> 
> That is a governance issue. It should probably be [nearly] written in
> stone and applied equally to all problems and decisions.
> 

Unfortunately, things are actually more complicated than that.

I suspect that none of the figures "minimal", 1.5% nor 3.4% are
actually accurate, due to "survivorship bias" (survive to be tested).
This is both due to large variance in results, and Google and FB
disagreeing on impact of the record type hack.

I think Attributing the differences to survivorship bias (or other
similar statistical bias) makes much more sense than attributing the
differences to random chance (I presume the sample sizes are large
enough to easily resolve even 0.1% differences) or a testing mistake.

If asked to guess which result is the closest to the true value, I
would guesss Google's (which is also the largest value). But I do
not have any idea even which direction the true value is (often in
studies it is rather easy to guess the direction of the true value,
even if one can not guess the correction magnitude).

The nasty issue in testing is that there are several classes of
connections, with quite widely varying properties:

1) Residential wired
2) Wireless Mobile
3) Enterprise (includes some schools)
4) Satellite (most probably of minimal use).

I would expect that with residential wired, the failure rates are
minimal, whereas with Enterprise, the failure rates would be pretty
substantial. With wireless mobile in the middle. I have no idea how
satellite would stack up.

I suspect the main factor in differences was proportion of enterprise
networks that were tested. Which would imply that the enterprise
failure rate is much higher than 3.4%. And even getting the failure
rate reduced to 1%, the enterprise failure rate would still be
substantially higher than 1%.


And analyzing individual middleboxes to determine the kind of
intolerance is only useful for guiding what kind of modifications to
test on the field, since estimating any useful statistics from
just the devices or software behavior is virtually impossible.


-Ilari