IETF Logo Mail Archive

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

"Salz, Rich" <rsalz@akamai.com> Thu, 19 October 2017 14:15 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 2A2BC1320D9 for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 07:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 sjIiQ2glnERc for <tls@ietfa.amsl.com>; Thu, 19 Oct 2017 07:15:28 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 0133D1331D9 for <tls@ietf.org>; Thu, 19 Oct 2017 07:15:27 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9JEE9Ir011136; Thu, 19 Oct 2017 15:15:26 +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 : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=U4ttLm8/A+p/3+qNr/G5aUzT0hVa1eejxFt0DFlMKXs=; b=FQi4ABQd9l3HAOBneEFJUwYzNNO4UK94YMT59diSvQpY58MqNq2XlMFHpydXRjuXy04q 49c3M6smPRMplxx23eEiiM4df8j/jeYolelzZtcRDK+3QjgOcJuIn5/ppYvdeApfEkjF 5rJ0/lwFdTzImWI3MMidopkmNEzpagSAVd+iMK5TCESzr9ePMxUI/ACVaa9GxgNYrggE DblZPGkjzdi/xenqU4zysO2jhVEyScGp4vHh3TL/F5aemoNf+1wqwG9otq0mzuRS4fnv Ox6kbqhNxKC48wGVywlrYbtRQm9ckG3O4RIhnERqBBrZHgUmiB7uPSnkprcVuv9chgrm Mg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2dpe9daw2j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 15:15:26 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9JEBcCS016303; Thu, 19 Oct 2017 10:15:24 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dkdwufgpj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 10:15:24 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag3mb3.msg.corp.akamai.com (172.27.123.58) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 19 Oct 2017 10:15:20 -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; Thu, 19 Oct 2017 10:15:20 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Paul Turner <PAUL.TURNER@venafi.com>, "Kaduk, Ben" <bkaduk@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgA==
Date: Thu, 19 Oct 2017 14:15:19 +0000
Message-ID: <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <a599d6ad-54db-e525-17d6-6ea882880021@akamai.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com>
In-Reply-To: <71e75d23f4544735a9731c4ec3dc7048@venafi.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.26.0.170902
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.65]
Content-Type: text/plain; charset="utf-8"
Content-ID: <C583BEC75E7D4B4EB657A9AC8A04BF08@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , 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-1710190196
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_05:, , 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-1710190196
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vXRmC2GJuY4J2GYucWCAc8OUR7E>
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: Thu, 19 Oct 2017 14:15:29 -0000

➢     I guess the basic question I'm asking is that if a third party is so powerful that they can do what you describe, aren't they going to force an even more effective method (trusting their CA so that they can terminate the connection as a middle man) on clients so that they don't have to coerce every server?
    
The stated goal of this work (and its predecessor) is to allow enterprises to capture traffic for later debugging and analysis.  The client could be coming in via the generic public Internet, with a stock browser.

Your question points out a danger of this mechanism: it becomes all too easy to “escape” and enable nationwide wiretapping.

Make sense?

v2.23.0 | Report a Bug | By Email