Re: [TLS] Industry Concerns about TLS 1.3

Xiaoyin Liu <xiaoyin.l@outlook.com> Fri, 23 September 2016 21:00 UTC

Return-Path: <xiaoyin.l@outlook.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 3FB5D12B4C1 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 14:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.718
X-Spam-Level:
X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 LCBkZE836X0O for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 14:00:03 -0700 (PDT)
Received: from COL004-OMC3S3.hotmail.com (col004-omc3s3.hotmail.com [65.55.34.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5901912B504 for <tls@ietf.org>; Fri, 23 Sep 2016 14:00:03 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.55.34.136]) by COL004-OMC3S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 23 Sep 2016 14:00:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jHuZpLf1/xCzCHH+jSGYWhL0xGS5Jn8+scXTF1pEChk=; b=ZSLk4zZDDeT1J3OUjtiux4K7s8u6ak7MBwP5B9EyT7U3Ks69VOjzQpLrjO5caqbtiTPA/8p5LtV6/PuXnwlh6+ktBMBh796f8qKQ2wmbFArY+iRRqDg+0ByqU23Y11se/p8H+fgsTa+4tWMB5c6wimx8PHeAM8Chg60e4tyCiwcEtdr8IKu9gV5WULcsYLi1WvFbovVr3XCd0Jn+jVJbZwX0UgpI4Vm2YN7uhdxujjHv80kiNyqYZXYk55/V8kzXRPsq2NbofasBHL5b8w41MqaHMNIwDaNh1HHtbZE0dRp6wMAKk+lyRO7kWeP+h5C2ZT/YzaFfTr6HAI2F6a9ehg==
Received: from SN1NAM02FT034.eop-nam02.prod.protection.outlook.com (10.152.72.58) by SN1NAM02HT222.eop-nam02.prod.protection.outlook.com (10.152.73.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5; Fri, 23 Sep 2016 21:00:00 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.72.53) by SN1NAM02FT034.mail.protection.outlook.com (10.152.72.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Fri, 23 Sep 2016 21:00:00 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0629.016; Fri, 23 Sep 2016 20:59:59 +0000
From: Xiaoyin Liu <xiaoyin.l@outlook.com>
To: BITS Security <BITSSecurity@fsroundtable.org>, "Salz, Rich" <rsalz@akamai.com>, "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
Thread-Topic: [TLS] Industry Concerns about TLS 1.3
Thread-Index: AdIU8WqWM9WBapZoQzyfqxiOaK25fQADrwVgABxJhIAADgIdgAAAS/+AAAFEjIAAAGtwAAACvFsAAARoUQAAAOAJQAADBekh
Date: Fri, 23 Sep 2016 20:59:59 +0000
Message-ID: <CY1PR15MB0778E06B122413B7D0C9E796FFC80@CY1PR15MB0778.namprd15.prod.outlook.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> <e24a06b8d0d04ccc80b9a55d83bf5606@usma1ex-dag1mb1.msg.corp.akamai.com>, <DM5PR11MB141926C5806296FFD7252A45F4C80@DM5PR11MB1419.namprd11.prod.outlook.com>
In-Reply-To: <DM5PR11MB141926C5806296FFD7252A45F4C80@DM5PR11MB1419.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=softfail (sender IP is 10.152.72.53) smtp.mailfrom=outlook.com; fsroundtable.org; dkim=none (message not signed) header.d=none;fsroundtable.org; dmarc=fail action=none header.from=outlook.com;
received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.72.53 as permitted sender)
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [mso6JccM1DMGPsQjXEgWtKFSSLki6RjK]
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1; SN1NAM02HT222; 6:U/6iPqXMOqhGD5rpzcb3Of3Z9CQrlblkG93n5ChKAzZOFn0deyBdD4lKf4jFeD/bBsPtrJkf32d3pbOSmG1DgvI/odnY4n+OERWTWM/H5qhWEw0zN4OGBKc/FTeuuqlKOakeLmP44JK3/PqXXCy+HUAEiSf2ik8DLFjYYB6n7SbtE0S/6yqmjrK3oRAxSSBQ13SNaYUvWflbQCtyGz2L26QRROqxi4vjoUHFi9mk9bt4cJPRMDjHhpvDPOZKEC/+pQAmeY+0HRbY2CVMnwDa6kCuNJ9ZKbGX6KhUYjRI9pk=; 5:F9YETPha38dbiD2VUtA4LQ+aH10NXiipaIz/yn2fsSsXqb6kkEdFHKyuLFhhBIXUvT8H2BI9JnK7T11FO/nwbmMSEnCro6wmiR8F1hKhWCZ0Ng1H02ycm0yhZYFjgtQIm58jEzg5In19Yy8ocl1zHQ==; 24:RDh4Cq/Jt/w+UPMQKiByf60tmMqcqURrPnjJ3fnMqKSyjWNH+06dSPKp4pgugEGmz23CXmV5/gGyGrqMmH0HYPDFVvFVP3fJzBYI94TQf+w=; 7:KKcjYPywONemxtOnu5BrpSI3Gh0drRONaXhYrGQCvKy0azozpHlr/yD9dDESi9N6kIAItgXkRLssL3eGbLcw4Mdet5WoBjrkpbIs7SE06hKbM4foN3o0tvhiw+QqOy1IhSVQXbILi7qwFzgeSa6//ulYi+ROmB9ufdRm4L0CLtWnB1t4Iuvn+eKMbWyNs6XR0s3dKrae7SNvua7tMRlIUNxmQ2e2Ev1EFjhg7j7uQSDJ3ou8Flq6ig+7FruARZZHx2iWUFsruihyqJNIUOdgiDcqF5e0+V2MGa7fMN2orlevlNihzTlCPEQREEaBqB4g
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT222; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: df01d617-047c-426f-12d8-08d3e3f494d1
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:SN1NAM02HT222;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM02HT222; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT222;
x-forefront-prvs: 0074BBE012
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0778E06B122413B7D0C9E796FFC80CY1PR15MB0778namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2016 20:59:59.5395 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT222
X-OriginalArrivalTime: 23 Sep 2016 21:00:01.0858 (UTC) FILETIME=[7399CA20:01D215DD]
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Y5lkbdtZkYWmcGnFJ0hroiU5Nw0>
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 21:00:06 -0000

Andrew,



I don’t understand why your “choice is being removed”, because you can keep using TLS1.2 in your internal network, can’t you?



Best,

Xiaoyin



From: BITS Security<mailto:BITSSecurity@fsroundtable.org>
Sent: Friday, September 23, 2016 4:31 PM
To: Salz, Rich<mailto:rsalz@akamai.com>; nalini.elkins@insidethestack.com<mailto:nalini.elkins@insidethestack.com>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3



Rich (et al.) -- I understand where you are coming from but I will poke a little bit at this portrayal.

We are not here hat-in-hand asking for a return to RSA key exchange to the proposed standard.  We do however want to raise our concern (and hopefully your awareness) of what appears to be an unintended consequence of the move to PFS-only choices.

What is happening from our perspective is choice is being removed and an adequate replacement has (seemingly) not been identified.  This lack of choice may not affect everyone and every use-case but it will predictably affect large, complex, highly regulated enterprises in a serious manner.  This is a classic case of security requirement being in conflict with a different security requirement.

IETF protocols are run extensively both on the public Internet and within private enterprises.  Any decisions made by the TLS Working Group will affect both environments, and the needs and requirements of both environments should be considered.

-Andrew


-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: nalini.elkins@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3


> 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 _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls