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

"Salz, Rich" <rsalz@akamai.com> Tue, 24 October 2017 19:23 UTC

Return-Path: <rsalz@akamai.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 2D0E8138F9C for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 12:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 MAiaJ92MyDSe for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 12:23:16 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683411386F3 for <tls@ietf.org>; Tue, 24 Oct 2017 12:23:16 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9OJN56B000498; Tue, 24 Oct 2017 20:23:14 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=kEYZepiBAPK6lNhsF/YEhvd8laAvu/QNObfp+KD1bQU=; b=kbiDjnL5bBuYeUoAE15GL3dz2uyxOsM30bjygYx9kiPFisKsbiLfJ2CtcU/oisZoiuf+ 6AAgdXCLGMBmHzk5DkC9MxcyqOYMVwK2a2azvjtTLef+8j411LI2w3QVKIkTL6yTj06j g+X5fysa6vlNel4TXgRvjYtiBlAJqLpjr7R0mrwZ8As8P/rtybsm95ZxwIHb6UlgD4Er 7c959s93y0L58yyfZ/JeVA82/+FAF21fn3hrwtXDeqL7gBJfRdQeiQ6+JRSocbnL9RYz WiSlXLecnlO/xZvCWEIq2sAo+3cdP37zw7XLclMtGwdzbSwavQ4jIlmyxEpqWZh40C7t 1A==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2dquad30mk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 20:23:14 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9OJKXX8028206; Tue, 24 Oct 2017 15:23:13 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dr1ju9xnj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 15:23:13 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 15:23:13 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 15:23:12 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 24 Oct 2017 15:23:12 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "David A. Cooper" <david.cooper@nist.gov>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgA
Date: Tue, 24 Oct 2017 19:23:12 +0000
Message-ID: <FB95CAC8-C967-4724-90FB-B7E609DADF45@akamai.com>
References: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov>
In-Reply-To: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.119]
Content-Type: multipart/alternative; boundary="_000_FB95CAC8C967472490FBB7E609DADF45akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240265
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240265
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ESeNbpv0jJOi-lxIoXS10U3FLuc>
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 19:23:18 -0000

I use an airplane as an example of a “captive” population, substitute any similar group you want.



  *   Yes, any box that sits between the client and the server can drop traffic for whatever reason it wants. Such a box could today drop any traffic that is protected using TLS.

True, but that’s not the point.  The point is by adding this extension into the clientHello, we are providing middleboxes with another knob to control traffic.  I think we want to avoid that. And keep in mind it’s not just HTTP, but *any* TLS-using traffic, such as many VPN’s.  It wouldn’t necessarily enable spying, but it could be used to guarantee that all traffic is amenable to spying.

As for how would such clients get promulgated?  Some simple scenarious include “surf for free on your flight, but use our Chromium-based browser to do so, available for free here.”    How many people on the plane would click and download?

> Proponents of this draft are interested in visibility within the data center, and have no interest in using this capability in any scenario in which a browser would be the client.

How do you propose to guarantee that?  As Stephen pointed out, we have no way to prevent this from “escaping” on to the public Internet, and no way to prevent captive audiences from being forced to comply.