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

Yoav Nir <> Tue, 24 October 2017 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 720561395E5 for <>; Tue, 24 Oct 2017 12:36:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n5aM2oqNMoYC for <>; Tue, 24 Oct 2017 12:36:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 995F1138A38 for <>; Tue, 24 Oct 2017 12:36:04 -0700 (PDT)
Received: by with SMTP id m72so13410240wmc.0 for <>; Tue, 24 Oct 2017 12:36:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=74GMhPCOEZDEod9Q/uKvUc9nIZaY1y99zB/a97QwE+c=; b=sxgCnM8I+P/qc65/vipLuJW6yWvs0laKY5cXDWjKuFXI9ZLRi3vwc7AV/Oruh2U5r0 86GcQCwWrZKf/kh4r3DsR28DbEqxFKNZKj1Y7kWZDt5D32AJMxuUrJAsdQrKDFnMZ7C5 rCcBIOScrvJAFX1kHVcPJ11GK4E8XEQgjhEtSGGfOKn16wkPLQ0KjEh80w+xNgZVZk06 29XNhI1ThPaqkfoMyhrtbssm5curCKaCtRL6fA7RibiAuTVMcRAYQUWrv++idI7qgEdz uqsUSNeBzaPpSTfSNV85BziIPAuV316INhr1LZisxnE6/NMDk6cKrJPw+3GNBlFoHtoy 1xDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=74GMhPCOEZDEod9Q/uKvUc9nIZaY1y99zB/a97QwE+c=; b=UoBi/hZzdgkvFGkNJts5JQJD2GXqdqWnJ06T2iy2xAGkGOipBq2kKpgkOA5SQcj0Ms F9OZDnPGf4L84CXhcIlV88J1QmPCzptcC2XsV7AecM+znd3cjwqefbqf/6XGoQMa83OL JmStGiFTq/8xBXMZi3jRjAMoOBBxfwK7dYf1t5qvDQy3UQK1MIl+1gdOMm87fjlKiu5l 4++KaICioioFtsdanaKM2CePQCucys+3B/FjV9Pnc5D+D0qUnvHwB2Zr9BUO5ANmHVm8 qk1yMF8NmQCyfYKhsrCX5NC319qBP2cLmp5tTeu4Xs7eHLR58NrmjOeIbBHPArUpXOFZ pijQ==
X-Gm-Message-State: AMCzsaWTngQUCjyicrBp+9J9P04sAEB/Xz0+eo7rwBCZ1J/lyhE4fBep 5FWtJEGHqvqO4dssIGurvsg=
X-Google-Smtp-Source: ABhQp+RGZfWcHo/35TKb2RGWijUMGOZgL4rDQ+YsCBB+uSk/IRZb6Gjx94Lzl6UTbate65+RIFQZmg==
X-Received: by with SMTP id p25mr55858wma.154.1508873763134; Tue, 24 Oct 2017 12:36:03 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id r2sm1064696wmb.38.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 12:36:02 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Tue, 24 Oct 2017 22:36:00 +0300
Cc: Rich Salz <>, "David A. Cooper" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Ralph Droms <>
X-Mailer: Apple Mail (2.3445.1.7)
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:36:06 -0000

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