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

Yoav Nir <ynir.ietf@gmail.com> Tue, 24 October 2017 20:38 UTC

Return-Path: <ynir.ietf@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 5FDAE1393AF for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 13:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 LiYnoZRt8om9 for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 13:38:25 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 74A341390EE for <tls@ietf.org>; Tue, 24 Oct 2017 13:38:25 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id y39so21959686wrd.4 for <tls@ietf.org>; Tue, 24 Oct 2017 13:38:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ju1hyBCneDji1w0NBil1mXtniRCO3YGrcO0MkGL53fI=; b=W8Al1efrtPgpMS4KgXxVh2nYnlU2SijVVWJf+dOj3nEujOeKq3dnpy8d9St46uuOoI UQhkiqOHKS4soqIksMcBwlztYF/YZfoj0I4kw86iDiAnWoYmEMqjAtSYUqAs5ZXGDWpp 9/HRpS1BUAmRZz0H26aszuYOJqfQoQMJm3m/cIFtNpQWGtWmRTge41GFekU7qp4ycsj5 oFhVKRsVXcAqQNCW+7D1F86X9/XttfrS63Ln7RKncjRPDhullCOjLxG37vrPCyt2A+9U Bo+vAzjg27011yUbLZHWlbPYsc4xzsJS5xJlrBHSUSint2WW8WlW3Yt5slHq70dsjIWK yPUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ju1hyBCneDji1w0NBil1mXtniRCO3YGrcO0MkGL53fI=; b=sDSUIhUVBNAwa3nFiZk7ll/fJP5f5D+HLgfLRm59XOMetRG5xbED8fk2D4FAuwVdxL ymN3LngU6TwNzo1bkBeiPVkzxBCgYRXTA9QbYdvHGUM2P6TvwjyuLy4oh6CiCFPWGisk 5pijUtew1ZqQJUWqK4XwwPHFTVawe9OglMYgI64L7A/le4+BjxCpcNKX6WJwov1GFchC IpY9Ie+Q7vAJndY5qD9hTPENXb1ly1bBmtzN4M/szZ25w9Bs0t+TfuEtrG/ybBCpa94q Vq4y0tm5cOfnVP8Rz6OsIQ+5FfEtO4R9ZVCvxVJr7lCzkgHXmsHTroyX+3reXFxunjWb QMKg==
X-Gm-Message-State: AMCzsaXmQ0LoLZuVYqs/R/EZax3TLUmCJzoRZ5k1DoljuuGMCscZ6IYE AFzYVAIUOBGzIY5x7UrEiPljaAnc
X-Google-Smtp-Source: ABhQp+Tev+50TGJrczye99qLS5CUqb2hTtdLc9CEIwlY5NMcTbr+SguVweU/NjGDmoNqzplAUpj7zg==
X-Received: by 10.223.199.205 with SMTP id y13mr16242375wrg.71.1508877503931; Tue, 24 Oct 2017 13:38:23 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l80sm1212942wmb.2.2017.10.24.13.38.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Oct 2017 13:38:23 -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 <ynir.ietf@gmail.com>
In-Reply-To: <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov>
Date: Tue, 24 Oct 2017 23:38:20 +0300
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com>
References: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov> <FB95CAC8-C967-4724-90FB-B7E609DADF45@akamai.com> <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov>
To: "David A. Cooper" <david.cooper@nist.gov>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dI11CXuSJUZ4GRyMgcjdBWr8CGs>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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: Tue, 24 Oct 2017 20:38:27 -0000


> On 24 Oct 2017, at 22:54, David A. Cooper <david.cooper@nist.gov>; wrote:
> 
> Why would these schools settle for a half measure that only allows them to snoop on traffic between their students and servers provide the keys to their Internet traffic to the schools? If a school wants to snoop on its students' traffic, it would do so in a much easier way than using draft-rhrd-tls-tls13-visibility, in the same way that some enterprises today use middleboxes to inspect all outgoing traffic.

Yeah. I used to write such middleboxes. They’re a nightmare to deploy in all but the most orderly of enterprises. You need to have all clients trust the middlebox CA. Fine, so the Windows computers get that installed through SMS or GPO or whatever the central configuration feature is called these days. The people with Macs have to figure it out for themselves, and the same goes for people with phones. Oh, and also for people who use Firefox, because that browser comes with its own trust store. The people on this list can probably figure it out with a little web search. A school with a thousand students all bringing their own devices? Good luck.

> This browser that students would be required to use would be one that has a CA controlled by the middlebox installed as a trust anchor. Whenever one of the students' clients tries to connect to an external secure site, the middlebox-controlled CA issues a certificate for that site so that the connection can be terminated at the middlebox. The middlebox then establishes a secure connection with the end server, thus setting up the middlebox as a MiTM.

It’s one thing to say that SchoolBrowser (conveniently located in the app stores of all phone and computer OS-es) works in this school (and all the others).  It’s a totally different thing to fill the app stores with “GrizzlyBrowser for Logan High School students” and “MustangBrowser for Mountain Crest High School students"

> There are already middleboxes on the market today that do this. They work for all outgoing connections and don't require any cooperation whatsoever from the outside servers that the clients are trying to connect to, and only expert users would notice the presence of the MiTM.

Unless they had to configure their browser themselves.  The support costs of these is tremendous.