Return-Path: 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 3D11412C0AD for ; Thu, 22 Sep 2016 16:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fciZWYw12AWp for ; Thu, 22 Sep 2016 16:41:32 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2558E12C092 for ; Thu, 22 Sep 2016 16:41:32 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id d69so60164829ybf.2 for ; Thu, 22 Sep 2016 16:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wT+wag2dFtVlTvc1iI93EpQc0dJtWF+Fxh5vp4jkhFo=; b=Qhtn4vSS8zONHDbE2v+FWd+XO5qFIrJ3xAAKVasvZFyjPiyIQ+Nz8KsVQRzEsL1c+P bEIr6p6retdnlgkOFGGriCw59rHqWbGOH+H6Uklkk0lnWicy1qsucf8ZKIVkt9IVW9f1 LGfjDHJMXuwve3Fe0XWZQXefrKvgN4EhJ0G67uuFiSVr7B9xcCc0AlymDTm2XnbjfTg/ FdxcixfUPZQ0EtxUqnaDRAuzCyMFMTPOU6YdsuG5ZBo+uhAQlBVC4wSyyyBy0gj60jk9 j55VRHq2Vwn1sV2a8XnWUEe0Hw8JSFt6sETAc5UaOGcHoKwy2QHqloqZpsURa6fC3pQn AP+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wT+wag2dFtVlTvc1iI93EpQc0dJtWF+Fxh5vp4jkhFo=; b=UgW2PvcKum8oSx7uwn/Enkko9Qs1Cihq7P68b9su7xMizvSFmZKsWxxoJ7G8AI4aaJ 6pc+YUTv6fuMiVSwjC7v2MTzkJNSC8zetUrOfdUvI6s2Vj3P/uWMfhzoZ/G/JF6yXXVN lFuGl/NGq6rFzoJeCDAIiYsa7GCppT4RkZpxq4qMj0klPh3VpKBhf+t1bjl1GTzSGIbu f6W2kC1DFcpEl6BpdLKGg7UwaNU4N0k1blsI+ZQeclyRXqwyMGzDovjQHgBwuGvDxrd8 udwP0Bvkb+N1ESrrocWNcMXvjVQwzOjZOBr3r60lU2PHDQJwIVTWyVEPHXhlNHOezjgQ GLVQ== X-Gm-Message-State: AE9vXwNTUHvhW2888acU1NTMReL3PomPS19/wlAQssn8dgkD8u/ZGL5K44Kcjy3tPTbmSSx9SzeVGzoVNh/tVQ== X-Received: by 10.37.171.201 with SMTP id v67mr3618792ybi.177.1474587691345; Thu, 22 Sep 2016 16:41:31 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.174.8 with HTTP; Thu, 22 Sep 2016 16:41:00 -0700 (PDT) In-Reply-To: References: From: Hugo Krawczyk Date: Thu, 22 Sep 2016 19:41:00 -0400 X-Google-Sender-Auth: 8RHF4LezueQifXJNEOoLe7zIF2g Message-ID: To: BITS Security Content-Type: multipart/alternative; boundary=94eb2c1855a2886baa053d213316 Archived-At: Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 23:41:36 -0000 --94eb2c1855a2886baa053d213316 Content-Type: text/plain; charset=UTF-8 If the problem is the use of forward secrecy then there is a simple solution, don't use it. That is, you can, as a server, have a fixed key_share for which the secret exponent becomes the private key exactly as in the RSA case. It does require some careful analysis, though. But maybe I misunderstood the problem and maybe I should not be putting these surveillance-friendly ideas in people's minds... Hugo On Thu, Sep 22, 2016 at 1:19 PM, BITS Security < BITSSecurity@fsroundtable.org> wrote: > To: IETF TLS 1.3 Working Group Members > > My name is Andrew Kennedy and I work at BITS, the technology policy > division of the Financial Services Roundtable ( > http://www.fsroundtable.org/bits). My organization represents > approximately 100 of the top 150 US-based financial services companies > including banks, insurance, consumer finance, and asset management firms. > > I manage the Technology Cybersecurity Program, a CISO-driven forum to > investigate emerging technologies; integrate capabilities into member > operations; and advocate member, sector, cross-sector, and private-public > collaboration. > > While I am aware and on the whole supportive of the significant > contributions to internet security this important working group has made in > the last few years I recently learned of a proposed change that would > affect many of my organization's member institutions: the deprecation of > RSA key exchange. > > Deprecation of the RSA key exchange in TLS 1.3 will cause significant > problems for financial institutions, almost all of whom are running TLS > internally and have significant, security-critical investments in > out-of-band TLS decryption. > > Like many enterprises, financial institutions depend upon the ability to > decrypt TLS traffic to implement data loss protection, intrusion detection > and prevention, malware detection, packet capture and analysis, and DDoS > mitigation. Unlike some other businesses, financial institutions also rely > upon TLS traffic decryption to implement fraud monitoring and surveillance > of supervised employees. The products which support these capabilities > will need to be replaced or substantially redesigned at significant cost > and loss of scalability to continue to support the functionality financial > institutions and their regulators require. > > The impact on supervision will be particularly severe. Financial > institutions are required by law to store communications of certain > employees (including broker/dealers) in a form that ensures that they can > be retrieved and read in case an investigation into improper behavior is > initiated. The regulations which require retention of supervised employee > communications initially focused on physical and electronic mail, but now > extend to many other forms of communication including instant message, > social media, and collaboration applications. All of these communications > channels are protected using TLS. > > The impact on network diagnostics and troubleshooting will also be > serious. TLS decryption of network packet traces is required when > troubleshooting difficult problems in order to follow a transaction through > multiple layers of infrastructure and isolate the fault domain. The > pervasive visibility offered by out-of-band TLS decryption can't be > replaced by MITM infrastructure or by endpoint diagnostics. The result of > losing this TLS visibility will be unacceptable outage times as support > groups resort to guesswork on difficult problems. > > Although TLS 1.3 has been designed to meet the evolving security needs of > the Internet, it is vital to recognize that TLS is also being run > extensively inside the firewall by private enterprises, particularly those > that are heavily regulated. Furthermore, as more applications move off of > the desktop and into web browsers and mobile applications, dependence on > TLS is increasing. > > Eventually, either security vulnerabilities in TLS 1.2, deprecation of TLS > 1.2 by major browser vendors, or changes to regulatory standards will force > these enterprises - including financial institutions - to upgrade to TLS > 1.3. It is vital to financial institutions and to their customers and > regulators that these institutions be able to maintain both security and > regulatory compliance during and after the transition from TLS 1.2 to TLS > 1.3. > > At the current time viable TLS 1.3-compliant solutions to problems like > DLP, NIDS/NIPS, PCAP, DDoS mitigation, malware detection, and monitoring of > regulated employee communications appear to be immature or nonexistent. > There are serious cost, scalability, and security concerns with all of the > currently proposed alternatives to the existing out-of-band TLS decryption > architecture: > > - End point monitoring: This technique does not replace the pervasive > network visibility that private enterprises will lose without the RSA key > exchange. Ensuring that every endpoint has a monitoring agent installed > and functioning at all times is vastly more complex than ensuring that a > network traffic inspection appliance is present and functioning. In the > case of monitoring of supervised employee communications, moving the > monitoring function to the endpoint raises new security concerns focusing > on deliberate circumvention - because in the supervision use case the > threat vector is the possessor of the endpoint. > > - Exporting of ephemeral keys: This solution has scalability and > security problems on large, busy servers where it is not possible to know > ahead of time which session is going to be the important one. > > - Man-in-the-middle: This solution adds significant latency, key > management complexity, and production risk at each of the needed monitoring > layers. > > Until the critical concerns surrounding enterprise security, employee > supervision, and network troubleshooting are addressed as effectively as > internet MITM and surveillance threats have been, we, on behalf of our > members, are asking the TLS 1.3 Working Group to delay Last Call until a > workable and scalable solution is identified and vetted, and ultimately > adopted into the standard by the TLS 1.3 Working Group. > > Sincerely, > > Andrew Kennedy > Senior Program Manager, BITS > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1855a2886baa053d213316 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the problem is the use of forward secrecy th= en there is a simple solution, don't use it.
That is, y= ou can, as a server, have a fixed key_share for which the secret exponent b= ecomes the private key exactly as in the RSA case. It does require some car= eful analysis, though.

But maybe I mis= understood the problem and maybe I should not be putting these surveillance= -friendly ideas in people's minds...

Hugo




On Thu, Se= p 22, 2016 at 1:19 PM, BITS Security <BITSSecurity@fsroundtabl= e.org> wrote:
To:=C2=A0 IET= F TLS 1.3 Working Group Members

My name is Andrew Kennedy and I work at BITS, the technology policy divisio= n of the Financial Services Roundtable (http://www.fsroundtable.org/= bits).=C2=A0 My organization represents approximately 100 of the t= op 150 US-based financial services companies including banks, insurance, co= nsumer finance, and asset management firms.

I manage the Technology Cybersecurity Program, a CISO-driven forum to inves= tigate emerging technologies; integrate capabilities into member operations= ; and advocate member, sector, cross-sector, and private-public collaborati= on.

While I am aware and on the whole supportive of the significant contributio= ns to internet security this important working group has made in the last f= ew years I recently learned of a proposed change that would affect many of = my organization's member institutions:=C2=A0 the deprecation of RSA key= exchange.

Deprecation of the RSA key exchange in TLS 1.3 will cause significant probl= ems for financial institutions, almost all of whom are running TLS internal= ly and have significant, security-critical investments in out-of-band TLS d= ecryption.

Like many enterprises, financial institutions depend upon the ability to de= crypt TLS traffic to implement data loss protection, intrusion detection an= d prevention, malware detection, packet capture and analysis, and DDoS miti= gation.=C2=A0 Unlike some other businesses, financial institutions also rel= y upon TLS traffic decryption to implement fraud monitoring and surveillanc= e of supervised employees.=C2=A0 The products which support these capabilit= ies will need to be replaced or substantially redesigned at significant cos= t and loss of scalability to continue to support the functionality financia= l institutions and their regulators require.

The impact on supervision will be particularly severe.=C2=A0 Financial inst= itutions are required by law to store communications of certain employees (= including broker/dealers) in a form that ensures that they can be retrieved= and read in case an investigation into improper behavior is initiated.=C2= =A0 The regulations which require retention of supervised employee communic= ations initially focused on physical and electronic mail, but now extend to= many other forms of communication including instant message, social media,= and collaboration applications.=C2=A0 All of these communications channels= are protected using TLS.

The impact on network diagnostics and troubleshooting will also be serious.= =C2=A0 TLS decryption of network packet traces is required when troubleshoo= ting difficult problems in order to follow a transaction through multiple l= ayers of infrastructure and isolate the fault domain.=C2=A0 =C2=A0The perva= sive visibility offered by out-of-band TLS decryption can't be replaced= by MITM infrastructure or by endpoint diagnostics.=C2=A0 The result of los= ing this TLS visibility will be unacceptable outage times as support groups= resort to guesswork on difficult problems.

Although TLS 1.3 has been designed to meet the evolving security needs of t= he Internet, it is vital to recognize that TLS is also being run extensivel= y inside the firewall by private enterprises, particularly those that are h= eavily regulated.=C2=A0 Furthermore, as more applications move off of the d= esktop and into web browsers and mobile applications, dependence on TLS is = increasing.

Eventually, either security vulnerabilities in TLS 1.2, deprecation of TLS = 1.2 by major browser vendors, or changes to regulatory standards will force= these enterprises - including financial institutions - to upgrade to TLS 1= .3.=C2=A0 It is vital to financial institutions and to their customers and = regulators that these institutions be able to maintain both security and re= gulatory compliance during and after the transition from TLS 1.2 to TLS 1.3= .

At the current time viable TLS 1.3-compliant solutions to problems like DLP= , NIDS/NIPS, PCAP, DDoS mitigation, malware detection, and monitoring of re= gulated employee communications appear to be immature or nonexistent.=C2=A0= There are serious cost, scalability, and security concerns with all of the= currently proposed alternatives to the existing out-of-band TLS decryption= architecture:

-=C2=A0 End point monitoring: This technique does not replace the pervasive= network visibility that private enterprises will lose without the RSA key = exchange.=C2=A0 Ensuring that every endpoint has a monitoring agent install= ed and functioning at all times is vastly more complex than ensuring that a= network traffic inspection appliance is present and functioning.=C2=A0 In = the case of monitoring of supervised employee communications, moving the mo= nitoring function to the endpoint raises new security concerns focusing on = deliberate circumvention - because in the supervision use case the threat v= ector is the possessor of the endpoint.

-=C2=A0 Exporting of ephemeral keys:=C2=A0 This solution has scalability an= d security problems on large, busy servers where it is not possible to know= ahead of time which session is going to be the important one.

-=C2=A0 Man-in-the-middle:=C2=A0 This solution adds significant latency, ke= y management complexity, and production risk at each of the needed monitori= ng layers.

Until the critical concerns surrounding enterprise security, employee super= vision, and network troubleshooting are addressed as effectively as interne= t MITM and surveillance threats have been, we, on behalf of our members, ar= e asking the TLS 1.3 Working Group to delay Last Call until a workable and = scalable solution is identified and vetted, and ultimately adopted into the= standard by the TLS 1.3 Working Group.

Sincerely,

Andrew Kennedy
Senior Program Manager, BITS




_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c1855a2886baa053d213316--