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

"David A. Cooper" <david.cooper@nist.gov> Tue, 24 October 2017 20:40 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 954731390EE for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 13:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.455
X-Spam-Level:
X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, MISSING_HEADERS=1.021, 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 gCr-h5wK6O2j for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 13:40:57 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [IPv6:2610:20:6005:13::150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989EA13A102 for <tls@ietf.org>; Tue, 24 Oct 2017 13:40:57 -0700 (PDT)
Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Oct 2017 16:42:20 -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 16:40:55 -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 v9OKeVvh019578 for <tls@ietf.org>; Tue, 24 Oct 2017 16:40:32 -0400
CC: "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> <BC5ABCF3-E36D-47B0-8D9B-D554B29359CF@fugue.com> <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com> <fa2b0ed8-2688-682c-de95-4c3a6d7921a4@nist.gov> <DF6E4D08-B27F-4785-A8FC-D6A90F7A8096@fugue.com>
From: "David A. Cooper" <david.cooper@nist.gov>
Message-ID: <eeb59ad8-84a1-10d8-d35d-15d2367b969c@nist.gov>
Date: Tue, 24 Oct 2017 16:40:38 -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: <DF6E4D08-B27F-4785-A8FC-D6A90F7A8096@fugue.com>
Content-Type: text/html; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/a2XbHnob6vWN_yBl0DoYNCZT58A>
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:40:59 -0000

On 10/24/2017 04:24 PM, Ted Lemon wrote:
On Oct 24, 2017, at 4:21 PM, David A. Cooper <david.cooper@nist.gov> wrote:
I'm not suggesting that cash strapped schools would use one of these devices. I'm simply saying that such a solution would be simpler and far more effective than trying to use draft-rhrd-tls-tls13-visibility to snoop on outgoing traffic.

Again, if that were true, then it would also be true that these devices would nicely solve the problem that draft-rhrd-tls-tls13-visibility solves.

Not at all. Visibility in the data center is a totally different problem than inspecting outgoing traffic. In the data center case the same organization controls the clients, servers, and the authorized listeners. That is very different from a scenario in which the organization that wants to listen in is different from the organizations that control the servers, and in which the organizations that control the servers are unlikely to want to grant this intermediary the ability to listen in on the traffic between it and its clients.

Also, in the data center case, there is no middlebox. Others, who know much more than I do about operational constraints in data center environments, have already argued that setting up a bunch of middleboxes would not be a viable solution.