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

"Salz, Rich" <rsalz@akamai.com> Fri, 20 October 2017 16:24 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 5275613331E for <tls@ietfa.amsl.com>; Fri, 20 Oct 2017 09:24:00 -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 G1pAvKKoxAK5 for <tls@ietfa.amsl.com>; Fri, 20 Oct 2017 09:23:58 -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 33D361332F2 for <tls@ietf.org>; Fri, 20 Oct 2017 09:23:58 -0700 (PDT)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9KGMPjY009961; Fri, 20 Oct 2017 17:23:54 +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=kQ6ZoA8APpICN8yob9UCldXwZNkq2tLsox888CEu9h8=; b=AOc5cPJ0wupBM90VmZSCH4wGnaffrixqPRwBiHTAfYAdPUAyHHZKC441ggeTZ2FqgMcn r87B6vHCi/29IC0ITxIxsHbZvBUdEBn4EVOdiH50NXU0UuQFksZYH2ltLP7bhZAzuBwb DyHJsnUVYPUJZ5YPSA4X7tpxD2WCjWFuGUoH54sLSS6ukpgV0wVdRJbkUGvNSV6FS62K SmJR7FdhfRiWNbEfgngbFctiMz9PG+gYJ0gSnU/+UYAGik2T1exhZ7Zyk2+en/PBwg34 rYqYuFmXbuXVNI0WqTPCL7fcWEnTVd0nNiJb9DDLKwK5f3vlPTjzUvAGGoCX3/0kR3/p lw==
Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2dngpbtxce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 17:23:53 +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 v9KGKpcm008773; Fri, 20 Oct 2017 12:23:53 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dkdwwev5p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Oct 2017 12:23:52 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb3.msg.corp.akamai.com (172.27.123.58) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 20 Oct 2017 12:23:51 -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; Fri, 20 Oct 2017 12:23:51 -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; Fri, 20 Oct 2017 12:23:50 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>, Darin Pettis <dpp.edco@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Thread-Index: AQHTO71yMz3yJYxp1UWiK0P85Z38q6LqPDwAgAFTKoCAAAWQgIAAANmAgAABFQCAAAA7gIAAAPWAgAADKYCAAALXgIAABTeAgAACs4CAAAEIAIAABEWAgAAZu4CAAAV4gIAAVLoAgAD/VwCAACX8gIAABqaA
Date: Fri, 20 Oct 2017 16:23:50 +0000
Message-ID: <1A894D0A-9B72-4649-A6E3-E9BC0C4F96AA@akamai.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <a599d6ad-54db-e525-17d6-6ea882880021@akamai.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <e8417cc424fe4bf3b240416dfffd807a@venafi.com> <B11A4F30-2F87-4310-A2F0-397582E78E1D@akamai.com> <fd12a8a8c29e4c7f9e9192e1a1d972d6@venafi.com> <D2CAAA44-339E-4B41-BCE0-865C76B50E2F@akamai.com> <d76828f02fc34287a961eba21901247b@venafi.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <c1c0d010293c449481f8751c3b85d6ae@venafi.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <E84889BB-08B3-4A3A-AE3A-687874B16440@akamai.com> <CAPBBiVQvtQbD4j3ofpCmG63MEyRWF15VL90NOTjeNqUOiyo6xg@mail.gmail.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <CY4PR14MB1368CBA562220D9A3604F0FFD7430@CY4PR14MB1368.namprd14.prod.outlook.com>
In-Reply-To: <CY4PR14MB1368CBA562220D9A3604F0FFD7430@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.26.0.170902
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.173]
Content-Type: multipart/alternative; boundary="_000_1A894D0A9B724649A6E3E9BC0C4F96AAakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_09:, , 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-1710200227
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_09:, , 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-1710200228
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dmXNd4dh_Ul8S1-P6mvMNbZjCAw>
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: Fri, 20 Oct 2017 16:24:00 -0000


  *   Expressly reacting to the viability of continuing to use TLS1.2 forever.

Nobody has said that, you are arguing a strawman.


  *   Industry groups will force us to use newer versions
  *   Policy standards will evolve in similar fashions.
  *   Likely there will be regulatory mandates in many of the marketplaces and business segments that large Enterprises participate in.

None of those even require TLS 1.2 yet, and it is a decade old.  Do you think any of them will jump from 1.1 to 1.3?  What timetable do you think that will happen?  A decade?  Five years?


  *   Software Products and Applications will attempt to remain current and will eventually sunset support for older protocol versions

Again, what timetable do you think that will happen?


  *   Business Partners or Government agency customers may require TLS1.3.

“May.”  Do you have any indication that this is a requirement?  Government tends to work either far in advance (like NIST post-quantum crypto) or to track industry.


  *   Internal Security Teams may require TLS1.3, at some point in the future.    And they should!    And why should we NOT want  and be able to utilize TLS 1.3 with it’s updated and enhanced capabilities.  We DO WANT THIS!   We just still need to run our networks and businesses and are badly wanting to work with the Working Group to assure our use cases can be accommodated, if at all possible.

Your use-cases can be accommodated.  You just need to spend some more money on server-side runtimes and key management.  Instead, you propose to force all clients into a weaker security posture.  I am sorry to be harsh, but as I explained in email messages yesterday, if you force clients to indicate that they are willing to have traffic be intercepted, then any middlebox can categorize, and deny or subvert, such traffic.  Again, don’t think of just national-scale adversaries, but your ISP or IP-in-airplane provider.

The proposal fundamentally changes the way TLS works.  And with the posted use-cases, it seems completely obvious to me that it *weakens* the protection afforded to the general population.

I believe I know why people want this now. They are worried that if TLS 1.3 goes out without something like this, then the market (standard widely available browsers) will not implement it. Let me assure you that this isn’t an issue. The extension would *never ever* make it to the MUST state, and the browsers would be unlikely to ever implement it anyway.

I have an alternate strategy proposal.  Configure your servers to only use TLS 1.2 or earlier, probably for at least five years. During that time, modify the server-side and analysis tools to record and use the extra key material you’ll need for TLS 1.3.