Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Stephen Farrell <> Tue, 24 October 2017 19:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6502813A039 for <>; Tue, 24 Oct 2017 12:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AvkyQdicU_Ky for <>; Tue, 24 Oct 2017 12:49:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1D7E1397F3 for <>; Tue, 24 Oct 2017 12:49:29 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 584B5BE2E; Tue, 24 Oct 2017 20:49:27 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e1L0bVYG2gsP; Tue, 24 Oct 2017 20:49:22 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 6EF53BE24; Tue, 24 Oct 2017 20:49:22 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1508874562; bh=g1G6XJmCVBDimQTh6J/d49frsDi2UJ3nJ7LYB4qFqug=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NxkHXGNkRMczV/Ngq5p9DbK6gXePuMLvuyThYGXK4wBAt8o3SQkWaun/Qu6OxoDA/ lcJ/2e0bFj7fhTh5yqcktKyLUwX+ahWUdJJNfgdZ94r8rch2dlXpmn5uQVVItrsKvu IGR+pwm9bf1pVZIeK/qtezcaSu4T+cpXiEdM6xDE=
To: Ralph Droms <>
Cc: Yoav Nir <>, "David A. Cooper" <>, "" <>
References: <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Tue, 24 Oct 2017 20:49:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nNAqpbxe6mfEEiQ0SULLj4MvXOJT1S0qg"
Archived-At: <>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Oct 2017 19:49:32 -0000


On 24/10/17 20:36, Yoav Nir wrote:
>> On 24 Oct 2017, at 22:27, Ralph Droms <>; wrote:
>>> On Oct 24, 2017, at 3:23 PM, Salz, Rich <>; wrote:
>>> I use an airplane as an example of a “captive” population, substitute any similar group you want.
>>> 	• Yes, any box that sits between the client and the server can drop traffic for whatever reason it wants. Such a box could today drop any traffic that is protected using TLS.
>>> True, but that’s not the point.  The point is by adding this extension into the clientHello, we are providing middleboxes with another knob to control traffic.  I think we want to avoid that. And keep in mind it’s not just HTTP, but *any* TLS-using traffic, such as many VPN’s.  It wouldn’t necessarily enable spying, but it could be used to guarantee that all traffic is amenable to spying.
>>> As for how would such clients get promulgated?  Some simple scenarious include “surf for free on your flight, but use our Chromium-based browser to do so, available for free here.”    How many people on the plane would click and download?
>> Just to make sure I understand, in this scenario the special-purpose browser could just as easily, today, be a browser with no TLS at all?   That is, I don't see why this scenario is specific to the visibility extension.
> Think of the children.
> We can’t just let them loose on the Internet, there’s predators out there. So we will snoop on their traffic.  To do that, we block all traffic that isn’t snoopable, and we do it at the edge router in schools.  All schools in our state are required by law to install a firewall that does this. And we get the mobile operators to do so as well (only for handsets in schools).
> Now either the mobile OS vendors make a browser that works in schools (at least with a setting), or the school recommends a third party browser that works in school. And best of all, this is *more secure* than regular TLS 1.3, because it also protects your children from Internet predators. Think of the children.
> You can’t make a claim like that for an HTTP-only browser, and worse still, it won’t work on much of today’s Internet.

Just to note that the only substantive difference between
draft-green and this is the please-screw-me extension in
the ClientHello and Yoav's argument above (with or without
all the obvious corollaries/variations) destroys that as
a defence for your latest effort to square this circle. (This
has been stated at least a couple of times/ways already.)

If you Ralph or Russ have some new arguments for your draft
that have not been countered already or wrt draft-green
then I wish you would raise those, because I've not seen any
that have survived. And if you have no such arguments then
I think it'd be a fine thing to admit that truth openly.

The underlying idea remains as bad as ever, for all the
reasons I tried to summarise at [1] (to which I'll add Yoav's
description above when I get a chance as it's a nice



> Yoav
> _______________________________________________
> TLS mailing list