Re: [TLS] Industry Concerns about TLS 1.3

Hugo Krawczyk <hugo@ee.technion.ac.il> Thu, 22 September 2016 23:41 UTC

Return-Path: <hugokraw@gmail.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 3D11412C0AD for <tls@ietfa.amsl.com>; 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 <tls@ietfa.amsl.com>; 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 <tls@ietf.org>; Thu, 22 Sep 2016 16:41:32 -0700 (PDT)
Received: by mail-yb0-x22d.google.com with SMTP id d69so60164829ybf.2 for <tls@ietf.org>; 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: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Thu, 22 Sep 2016 19:41:00 -0400
X-Google-Sender-Auth: 8RHF4LezueQifXJNEOoLe7zIF2g
Message-ID: <CADi0yUPZzLrPize4eKpASdM=2nm1h1T2UXs7_sdk2eDv=ku_2w@mail.gmail.com>
To: BITS Security <BITSSecurity@fsroundtable.org>
Content-Type: multipart/alternative; boundary=94eb2c1855a2886baa053d213316
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5LDNgrPI8JTzK6a7r3W5Q-VXlk4>
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: Thu, 22 Sep 2016 23:41:36 -0000

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
>