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

"David A. Cooper" <david.cooper@nist.gov> Tue, 24 October 2017 20:21 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 737D113F7F3 for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 13:21:49 -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 AdXKtQqf8Zyq for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 13:21:46 -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 8F7061394F2 for <tls@ietf.org>; Tue, 24 Oct 2017 13:21:45 -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 16:21:38 -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:21:44 -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 v9OKLWxT018193 for <tls@ietf.org>; Tue, 24 Oct 2017 16:21: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>
From: "David A. Cooper" <david.cooper@nist.gov>
Message-ID: <fa2b0ed8-2688-682c-de95-4c3a6d7921a4@nist.gov>
Date: Tue, 24 Oct 2017 16:21:39 -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: <88AB2AEF-D780-4A29-B9AE-6096CEBF2F7F@fugue.com>
Content-Type: text/html; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner-Information:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fQk735nmkeOz0TGMwHezIzTwkNQ>
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:21:49 -0000

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.

Those who are suggesting draft-rhrd-tls-tls13-visibility could be used to snoop on outgoing traffic are imagining a scenario in which the school (or other snooper) would make arrangements with each TLS-protected server that they would allow their clients to connect to receive copies of the keys that would be needed to decrypt the traffic. How effective would that be? How expensive would that be?

Besides, the scenario I described previously is just one possibility (although perhaps the easiest to implement). The software that the middlebox requires clients to use could just send the traffic in plaintext to the middlebox while falsely indicating to the client that the connection is secure. Plainly, if the attacker developed the software that the client is running, then there is no protection from the attacker.

On 10/24/2017 04:01 PM, Ted Lemon wrote:
On Oct 24, 2017, at 3:59 PM, Ted Lemon <mellon@fugue.com> wrote:
On Oct 24, 2017, at 3:54 PM, David A. Cooper <david.cooper@nist.gov> wrote:
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.

They are also quite expensive because they have to generate certs on the fly.   If you look at environments where these are in use, they tend to be either high-margin, or else low-use.   So e.g. you only redirect TLS connections that you absolutely need to intercept through the box; other connections are terminated normally.   Practically speaking, I don't see any cash-strapped school spending money on one of these devices.

BTW, if you find this argument unconvincing, consider why these boxes aren't being proposed for use as an alternative to draft-rhrd-tls-tls13-visibility-00.   :)