Re: [TLS] Industry Concerns about TLS 1.3

"Salz, Rich" <rsalz@akamai.com> Fri, 23 September 2016 19: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 E56CC12B00B for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 12:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.017
X-Spam-Level:
X-Spam-Status: No, score=-5.017 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, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 kKGL0geXSDLW for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 12:08:20 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8604B12B09C for <tls@ietf.org>; Fri, 23 Sep 2016 12:08:20 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F3F80433487; Fri, 23 Sep 2016 19:08:19 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C421B433483; Fri, 23 Sep 2016 19:08:19 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1474657699; bh=M1xL5iTxfgYvqJDWojkKYNydu2mbyS+XnletUY5a3WM=; l=2882; h=From:To:CC:Date:References:In-Reply-To:From; b=0NLVP7BqQ5FgY3c9ME024vX20s5BWMlIJDN1E9bgju1hZ9lW8RqADGYJdXN3zwebC Y6WJpIhSX/PctednZFbMqiNRHZLk/jEuWz3PoB0SnO5D0Aarc3rHNnnnmzbFTXd8ov fuh3/7pmxoY2RZjWalzH4t5QZ97/qZZjduFJDvq4=
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B28D41FC8C; Fri, 23 Sep 2016 19:08:19 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 23 Sep 2016 15:08: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.1178.000; Fri, 23 Sep 2016 15:08:19 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
Thread-Topic: [TLS] Industry Concerns about TLS 1.3
Thread-Index: AdIU8WqWM9WBapZoQzyfqxiOaK25fQADrwVgACSrSIAADgIdgAAAS/+AAAFEjIAAAGtwAAACvFsAAATvGdA=
Date: Fri, 23 Sep 2016 19:08:18 +0000
Message-ID: <e24a06b8d0d04ccc80b9a55d83bf5606@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <CO1PR07MB283F2C414B6478E993675DEC3C90@CO1PR07MB283.namprd07.prod.outlook.com> <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <CAH8yC8kgYzYXwJ01NkK7WYxD-diponWEQOd+MNHssm+bLHE54w@mail.gmail.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com> <CACsn0c=5vjzQmr=ah6sH1JzTj3peaKad7aCPertcqD4B2DLKiA@mail.gmail.com> <72011214.413503.1474650126973@mail.yahoo.com>
In-Reply-To: <72011214.413503.1474650126973@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.46.163]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KUZ2fwJ7ygs-MKcOgsHVaGAHYxE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Sep 2016 19:08:23 -0000

> It would be very interesting to get the network diagnostic and operations people (rather than the architects) of the above companies involved in this conversation.

Nothing has ever stopped them.  Never. Participation is as simple as joining a mailing list.  The IETF has been doing SSL and TLS for nearly 20 years.  It is not a secret.  It was incumbent on them to reach out and get involved.   

> Why don't we listen to each other?   I know at IETF, I often hear that we don't get enough operators to comment and give feedback.  Well, here you have some.  It may be that these companies have problems that are different from Google's (just as an example).

Don't try to equate "listen to each other" with "meet my requirement."  The message has been stated, very clearly, from individuals, WG members, through document editors and WG chairs and up to Security Directors:  static RSA is not coming back to TLS 1.3 .  Since before the last IETF this was the message, consistently.  So perhaps you should answer the question first -- why aren't *you* listening? :)

PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to prevent PFS in their existing deployment?  Why won't additional controls to prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So far all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to move to TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs in TLS 1.3 too.

Look, pretty much the entire world is being spied on by national-scale adversaries who are recording all traffic for eventual decryption and correlation.  *Almost everyone* is having their traffic surveilled. The problems of debugging a set of enterprise apps doesn’t amount to a hill of beans in that world. It just doesn't. Same for a particular industry's regulatory requirements. 

> Isn't our goal to have the best standards possible?   Any organism (including the IETF), needs feedback to thrive.

Oxygen, coke, and cookies too.

--  
Senior Architect, Akamai Technologies
IM: richsalz@jabber.at Twitter: RichSalz