Re: [TLS] Industry Concerns about TLS 1.3

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 28 September 2016 07:15 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 8D32512B3CF for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 00:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.917
X-Spam-Level:
X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 dAg50D9ItOo9 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 00:15:12 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2490612B091 for <tls@ietf.org>; Wed, 28 Sep 2016 00:15:11 -0700 (PDT)
Received: from [192.168.91.133] ([80.92.122.18]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MgXCF-1bcAMa3sEp-00NvMX; Wed, 28 Sep 2016 09:15:04 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: BITS Security <BITSSecurity@fsroundtable.org>, "tls@ietf.org" <tls@ietf.org>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <b8627383-8d58-b364-e52b-73327d273ea4@gmx.net>
Date: Wed, 28 Sep 2016 09:15:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9MtCjv1R2fQHu7XERmJL2KSssd7LoQT1j"
X-Provags-ID: V03:K0:uIJfdLijhgzp/gD4yrm0bD2gY1YR9FGO585nDPTI/YFXBORUsV1 7wvdagFIKrGTVgGSe3w1KDs5vhl2HP7dSrUlqEADItmysmmDv+79ALkWN5TUGsyXfbrvAtQ PIblO/c4W8RPOKu2x7lSE027u0sWV3m90wV/F1Q5eCow71clnZOuTcbNDFouQP7heBH1GZD 16/HD1d/9oeo5mimFKUBA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:0BzWBUDfvj0=:lKa2+OM+gPMAjkUJloh9FW GbqRqmIwRorjFAjc8qa18PZmGZZ5Hz803vuxQdpf3iDWsMj3irMZarCK+V5/jf9C4WFY6znmZ h9yXTQmWcMLY84v/6M89IpsvrNcYIxkXVHJGLf6d/zUYB2ECZK2euGy03FDNnPvT+qOsjAbcJ oMq2bylDHbrX4xBUSEXjhx0/Z9E0S2PVXIJxhRt5WAt3/lnJA+sAyMxoSeTTWGKJzGaZyTvqM qXxeQp770+jX7gxRPFAYn65Qwi3JzZQyzwV6gROENHkbvvlBEpepWmfzprdoO9qVCXuf2LV1n 4dXz98BfPMnrixQPB4dJI5dapSiVxKL2t7HScg88vQH3fsMbtlfCGkjldv8BdTX0dokzJlkCg WU7tKqD0Ed77Aa1qUTZkOyvRvEclCyNJKSbpGGpfB10OM/0rKeOj/lVx9M0Bec2zrZHAizgOu hG9g2/u+aXTc1ez0Axt98QvjkpMq6hl+TdIgGQ7xl8fY59PUaAO9ANIgd0wkxplUKvJ2ymDct DhX1O0akwX0/00OR/DvRhukCsrsnRfESPKktBPtVz79nXg9WQE0udMhHm28z/PGkSXYRWxet7 Ie912nsIc/QTc0a+hhMWWheWwVPVKJTUCYDJQdgICYTPTdWibbdDOj/R/7an7/6AfoiHcctd3 XhCgRVWLqatfbflzh3aAsAqRSafG+Hrnj9GhzOCJPbRniObHK/MrYkG11WCBIINiW9hMNAeWY 1Ds5NyuAqJpHv+KfKxHutv0KYpNjDuC2lIFxQY2Fx6LO9jY6LTMFI40Rfko=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iLjNzBbn86vVLRuuU8IzVND2x-c>
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: Wed, 28 Sep 2016 07:15:14 -0000

Hi Andrew,

I am coming from a different industry, the embedded industry, and for us
at ARM the development of TLS 1.3 will help us to increase the security
of Internet of Things devices as well as to improve the performance of
the handshake. We are reaching out to developers and our partners to
tell them about the importance of randomness and keys generated on on
low end microcontrollers.

From reading your text it feels that you have been relying on technology
that intercepts security protocols in a way that follows an
architectural model that wasn't necessarily sound to begin with. Maybe
it is time to rethink the architectural choices you have made or at
least challenge your favorite deep packet inspection vendors a bit more.

Ciao
Hannes

On 09/22/2016 07:19 PM, BITS Security 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
>