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

"David A. Cooper" <david.cooper@nist.gov> Wed, 25 October 2017 14:50 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 2420413ED2D for <tls@ietfa.amsl.com>; Wed, 25 Oct 2017 07:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 4OEmzjQ8lu0i for <tls@ietfa.amsl.com>; Wed, 25 Oct 2017 07:50:22 -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 2B0E013EB4D for <tls@ietf.org>; Wed, 25 Oct 2017 07:50:22 -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; Wed, 25 Oct 2017 10:51:43 -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; Wed, 25 Oct 2017 10:50:20 -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 v9PEo03L011433 for <tls@ietf.org>; Wed, 25 Oct 2017 10:50:00 -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> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com>
From: "David A. Cooper" <david.cooper@nist.gov>
Message-ID: <f741b067-e7af-5231-4bb1-a0c2d151e6bf@nist.gov>
Date: Wed, 25 Oct 2017 10:50:00 -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: <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-NIST-MailScanner-Information:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/S5aK-q6sAlFE0eONonENQMijaMw>
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: Wed, 25 Oct 2017 14:50:25 -0000

This question is based on your that belief that this protocol will 
"escape" onto the public Internet, that browsers and other clients used 
by individuals will feel forced to implement it, and that clients will 
then be forced to enable the extension in order to get through 
middleboxes that would filter traffic based on whether or not the 
extension is present in the ClientHello. I've already explained why I 
believe that scenario will never happen, and so no I do not agree that 
it is a "fundamental change."

The idea of a client extension was added based on feedback at the Prague 
meeting in order to help prevent the protocol from being used over the 
public Internet, by preventing the protocol from being used without the 
client's knowledge. Obviously you believe that the method being proposed 
to address one concern introduces another concern. I do not share those 
concerns for the reasons that I've already stated.

I don't plan to comment on this issue any further, and doing so would 
just be repeating myself, thus just adding to the noise.

On 10/25/2017 10:28 AM, Salz, Rich wrote:
> ➢     Similarly, the best that TLS can offer in terms of privacy is that the
>      contents of the communication between the two endpoints is not seen by
>      anyone else *unless* at least one of the two endpoints (client or
>      server) chooses to provide the contents of the communication to some
>      other entity. draft-rhrd-tls-tls13-visibility doesn't change that.
>      
> Yes it does.  It signals on the wire to any observer that the client and server agree to this.  TLS never attempted to control what the client or server could do. But it never put any such signal on the wire. This is an important and fundamental change, and it allows traffic to be categorized and handled differently.
>
> Do you agree with that?
>