Re: [TLS] Industry Concerns about TLS 1.3

Yoav Nir <ynir.ietf@gmail.com> Thu, 22 September 2016 20:19 UTC

Return-Path: <ynir.ietf@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 CF06112B4D7 for <tls@ietfa.amsl.com>; Thu, 22 Sep 2016 13:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 QveQJpjT7shU for <tls@ietfa.amsl.com>; Thu, 22 Sep 2016 13:19:55 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 F1DC012B750 for <tls@ietf.org>; Thu, 22 Sep 2016 13:19:53 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id l132so168208805wmf.1 for <tls@ietf.org>; Thu, 22 Sep 2016 13:19:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2Vt+2jD2zVa3dpQu0DvlS1hX2yJuSEzT4okvl2r8PMM=; b=RAmU5LcDTPPYyNp2vxl0qf01O4jQOoW44HvB1OYxKnx1JQq8TDHJqSBDdwq2PH8Dp4 j+P/lzoV2c1w/pvCGyNQCmSnY8w7uDJtcHnaU5VVJz8XtrIu8o0Pr+/hPvH1tykIUl0i bQz5QXloNVsnz2Lb0jSspsq41lZu1VHGQUVktyBXxzazMMuuI9yULr7cxGWiNva61hPK HSS+0iIwmJ7QQNV2+gbpMJnC2BXT/BXcfC7fnDwRnlkGcJ9FOw8vwEVpxzrsavseAm2o KD8BAfR00/qZwrFHFtrC0BGQ+MYuaOf96EF/45fdL0HB0QLVBMBYWEgV/YwKneEp+9Um Vfpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2Vt+2jD2zVa3dpQu0DvlS1hX2yJuSEzT4okvl2r8PMM=; b=JhdIcb1gTca14Bas3iNmQ6y5pYeLz6PbaYHlecdxuIA02uPhjMJFNuVkNzwaLSqHJ1 4Ha8N3RSaYDb6r6rCjunDf6OmS8ogYc1+JC0KlcVWWG1iQ6dIfsE88f0orm6AXEr/fTl 6JWgFEmcC3zmauAVnqHcHYZR/yb2xwUQgcXZFkjPfSOA9p8I8p3K9OyYHn9jcmZgWddr FikfVBHoTc0UW2OscAYetYHx8ofLX6xRAs+5ALrdpk4bjPRG/6ZBL+9Mo311GVf7pDtz pxZNb1wRv31uCPNbznt/3Ix4iCONvVY3QyWpO/5/EvqbNLh5V2a247+z5NWJcTBfODfe malA==
X-Gm-Message-State: AA6/9Rn2LQNldmS+8kxbi85gp+tUMIcbtA8vt5p9na2U4v8VDiBnKThCztAJ6nsCn5jJWg==
X-Received: by 10.194.149.238 with SMTP id ud14mr3608997wjb.194.1474575592422; Thu, 22 Sep 2016 13:19:52 -0700 (PDT)
Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l3sm3724904wjp.17.2016.09.22.13.19.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 22 Sep 2016 13:19:51 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
Date: Thu, 22 Sep 2016 23:19:49 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <81FAAC3B-AD48-458E-BD23-4DEE0C7FE9BC@gmail.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
To: BITS Security <BITSSecurity@fsroundtable.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5Mwpng7UGeaGA4lIhyvcOXdTwQA>
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 20:19:57 -0000

Hi, Andrew.

Thank you for bringing these concerns to the list. I agree with Kenny that this is rather late, but it’s also true that I don’t think it would change the outcome of the consensus in this working group.

The quest to mandate FS in TLS-using applications goes back longer than this effort:
 - HTTP/2 (RFC 7540) has mandated it since draft -10 from February 2014.
 - The TLS BCP (RFC 7525) has mandating a preference for FS since version -00 or the individual submission (September 2013) and version -10 of the draft (February 2015) made the RSA key exchange a SHOULD NOT.

The latter is very significant, because that RFC is a bunch of recommendations for legacy applications.

I’m sympathetic to the argument about trouble-shooting the network, but not so much to the argument about keeping records.  I’ve taken the liberty of snipping most of your message, and interspersing my remarks with the parts where you shoot down proposed solutions.

> On 22 Sep 2016, at 8:19 PM, BITS Security <BITSSecurity@fsroundtable.org>; wrote:

<snip />

> 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.

That is true, but from my admittedly limited exposure to financial institutions, the employees there then to be given extremely locked-down workstations where they have practically no ability to install or uninstall anything. The mobile phone revolution actually helps to make this palatable, as employees get to do their personal business on their personal phones using the cellular rather than the employer’s network. 

> -  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.

This seems like a strange claim to me. On the one hand, you’re storing away the entire (encrypted) content of the TLS session. On the other hand you can’t scale the storage of a few dozen bytes of keys for each of those sessions?

> -  Man-in-the-middle:  This solution adds significant latency, key management complexity, and production risk at each of the needed monitoring layers.

And yet many content providers use such solutions as part of their production network. I’m not even talking about TLS proxy firewalls. I’m talking about so-called “SSL offload” gateways such as F5’s big-ip. They decrypt everything on the gateway and forward the requests to back-end servers. It does add complexity, but so does your regular monitoring hardware.

> 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.

If you can come up with something that will do all that without giving up on forward secrecy, I’ll be happy to help you write a draft.

Yoav