IETF Logo Mail Archive

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

"Salz, Rich" <rsalz@akamai.com> Tue, 24 October 2017 20:08 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 2468313A102 for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 13:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mSm_WEcUXmZo for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 13:08:00 -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 F2C82139938 for <tls@ietf.org>; Tue, 24 Oct 2017 13:07:59 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9OJv2IU016500; Tue, 24 Oct 2017 21:07:57 +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 : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=NLw4T8bwn0wpoxRJ3sxZ61/bns43ictpjFhDftM+E4I=; b=e6ct65iDXAGO3vyuiH+IwKBht63RccPkFMNiCIske+6nRmzkjIdmRW/6OSOctET386Ml Uaf6KiKzqSom4qX3oxrorkKWE4AJ186JDPA3et1zwMBGXJMzUm+VUzUR13SMjjEI3Q/d 1VyTqxHl2aIKksS0IFJI2NUJeAP/RtAQo44ut2s7boqM0k3LBzblL12d/O4R1XG2MHxj 1ZoACwe9YICPweYOaS85CmYJBTySzuVdWzbQkuNj15ZW8V0ovDhLTGqUSDjY3YPUF84n 6jLtmAK1JLi4aKWybMI1iqGqecDOKr7Af03zY6ZHp7dZ2Bz4DUN9zaI7sJzA64BVTOE+ hA==
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2dqxn6jncn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 21:07:57 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9OK6ldG004362; Tue, 24 Oct 2017 16:07:56 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dr1jvkvky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 16:07:56 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 24 Oct 2017 16:07:54 -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 16:07:53 -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: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAADpIA=
Date: Tue, 24 Oct 2017 20:07:53 +0000
Message-ID: <268446A2-8B62-4A3F-B63F-FA63A4C3A94E@akamai.com>
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>
In-Reply-To: <0f9073f5-271b-a741-1a1e-f20ebc506d61@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: text/plain; charset="utf-8"
Content-ID: <EAE71CA989A55D4C8EB1250CFA37F6B2@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_11:, , 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-1710240275
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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710240274
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/w2HnzKrf2lcu4PChHMZq-tb8VlA>
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:08:01 -0000

>  complicated-to-implement and largely ineffective solution such as 
    subverting draft-rhrd-tls-tls13-visibility for improper purposes?
  
The phrase “subverting for improper purposes” is inaccurate, and perhaps misleading.  We would be providing another cleartext signal and we have to expect that someone will use it; anything else would be naïve. All the discussions about “ossification” in the past two years should make that painfully obvious.

As for “improper purposes,” it’s something enabled by the protocol, even if it’s not what the proposers intended it for.  But isn’t the whole story of the Internet? If the purposes are really improper, define things in a way that it can only be used properly, for whatever that definition is.

So far, we’ve seen that it can be used to segregate clients, open them up to stream modification, and the only justification has been that this is perceived easier to keep visibility as currently built by sharing static RSA keys.

Do I have that right?

v2.23.0 | Report a Bug | By Email