IETF Logo Mail Archive

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

"Salz, Rich" <rsalz@akamai.com> Wed, 25 October 2017 00:59 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 0AC1E1395ED for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 17:59:26 -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 BYAHouOhZ2FP for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 17:59:23 -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 5039C13A5BC for <tls@ietf.org>; Tue, 24 Oct 2017 17:59:23 -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 v9P0v4dJ007613; Wed, 25 Oct 2017 01:59:21 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=4bi0wFHTJ+a1BmSdKOLIDaKYK37dPpu7E31hG4Y6NMY=; b=XvLEp2T5W6Gk4hKNAvV7nNDMwWof9NreHn/t55p49tOyG0TmyNaIPrUoSuGwdxQLZ12d PxXPiHvPGbf7U4hCXPlIaqY6eyEvrYpXsDfYAvgcLFPaLDN6FRPgOIGTcxeSpeWqS5pl tgT+MvfJfiLK5oisHd8+ywC8U0UnYLai4nhrm3hkWL37AtIJK1JFmDtVrZKdCan9J858 BPi7JgRFG7XTao5CBgpw4rYcx907S3Y2IZpkuRS+e153vedHIbKTn7YtOVcnO4jRdSsA qckrC//P97U5aoQJChvgcis9MNjcQgE1adsc+Qx7ems/nFopQLhrsmdXDtYxBtbQZtME rA==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2dquad3uc9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Oct 2017 01:59:21 +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 v9P0udng017863; Tue, 24 Oct 2017 20:59:20 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dr1juapue-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Oct 2017 20:59:20 -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 20:59:19 -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 20:59:19 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "David A. Cooper" <david.cooper@nist.gov>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Thread-Index: AQHTTPr5Mz3yJYxp1UWiK0P85Z38q6LzpCgAgAABKgCAAAJqAIAABUSAgAAMJgCAAAjQAIAAAkoAgAAWo4CAACJOAIAABN6A
Date: Wed, 25 Oct 2017 00:59:18 +0000
Message-ID: <041E86E9-493F-4F20-8BD8-A48296E0AFBE@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> <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> <CY4PR14MB13686CD4119467FEEB5AC454D7440@CY4PR14MB1368.namprd14.prod.outlook.com>
In-Reply-To: <CY4PR14MB13686CD4119467FEEB5AC454D7440@CY4PR14MB1368.namprd14.prod.outlook.com>
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.32.65]
Content-Type: multipart/alternative; boundary="_000_041E86E9493F4F208BD8A48296E0AFBEakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_12:, , 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-1710250011
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_12:, , 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-1710250011
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/12B3VvvY0jVBvUGarFq3OrHHsNY>
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 00:59:26 -0000

> I'm not taking any risk.  The ability for a server to allow a third party to have access to data it is exchanging with a client already exists, and that ability isn't going away whether this proposal (or something similar) is standardized or not. As I've already pointed out, for the scenarios people are concerned about, the "attacks" being described would be much more easily carried out by some means other than draft-rhrd-tls-tls13-visibility.

Yes, you are taking a risk.  Or, rather, you are providing a way for any middlebox to force clients to acquiesce.  You might think it’s complicated, but it’s not.  There’s a perl script in the OpenSSL distribution that does something very similar (look for the TLS Proxy).

Servers have always had the ability to share whatever information they want with other entities.  We are not trying to change that.  What this draft does is force clients to become parties in that interaction and signal in the clear that they are doing so.  This is a really fundamental change to TLS.

> So, no I am not worried about the "risk" of creating a complicated way for servers and middleboxes to collude to do something that they can already do now in a simpler way.

I think you’re not getting it.  Sorry, probably my fault for not being a very good explainer.

v2.23.0 | Report a Bug | By Email