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

"David A. Cooper" <david.cooper@nist.gov> Tue, 24 October 2017 21:10 UTC

Return-Path: <david.cooper@nist.gov>
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 792A113F84E for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 14:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.476
X-Spam-Level:
X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 2T-z8ol8VUpO for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 14:10:22 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291BC13F847 for <tls@ietf.org>; Tue, 24 Oct 2017 14:10:22 -0700 (PDT)
Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Oct 2017 17:10:14 -0400
Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Tue, 24 Oct 2017 17:09:59 -0400
Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v9OL9kZ4022084 for <tls@ietf.org>; Tue, 24 Oct 2017 17:09:46 -0400
To: "tls@ietf.org" <tls@ietf.org>
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> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com>
From: "David A. Cooper" <david.cooper@nist.gov>
Message-ID: <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov>
Date: Tue, 24 Oct 2017 17:09:52 -0400
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: <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com>
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner-Information:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9Jaqu4vRLdx3WadA9vLxxCRgqnY>
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 21:10:24 -0000

As difficult as what you describe below would be, using draft-rhrd-tls-tls13-visibility to snoop would be much more complicated. They would need to need to get their "special" browsers onto all of the students' devices, but then, unlike in the scenario below, that would only be the beginning of what they need to do. They would need to active cooperation of every TLS-protected server that the students could connect to and they would need an infrastructure for obtaining and managing all of the keys that they would be getting from all of these servers. [In practice, of course, there wouldn't be that many keys since practically no servers would cooperate in this scheme.]

So, yes, setting up a scheme to snoop on all outgoing TLS-protected traffic would not be easy. However, draft-rhrd-tls-tls13-visibility would not make it easier than it currently is, as implementing something based on draft-rhrd-tls-tls13-visibility would be far more difficult than using currently available methods.

And, I don't buy the idea that if this extension is standardized that it will be implemented in commonly-used browsers. We don't have to "keep all the plates spinning" in order to prevent this extension from "escaping" on to the public Internet. This isn't something that could "accidentally" be implemented in browsers if browser vendors don't take extreme precautions to prevent it from happening. Browser vendors would have to pro-actively decide to implement this, and I don't see that happening. The idea that someone would set up a service that would only work if browsers implemented this extension, and then browsers would be "forced" to implement the extension so that this service would work isn't realistic.

A server that wanted to allow third party interception of traffic between itself and its clients wouldn't require this extension and then wait for browsers to implement the extension. It would just use TLSv1.2 with RSA key exchange (or something like draft-green-tls-static-dh-in-tls13), and then set up the interception capability without the client's knowledge.

On 10/24/2017 04:38 PM, Yoav Nir wrote:
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.