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>
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
Precedence: list

Hi, Andrew.

Thank you for bringing these concerns to the list. I agree with Kenny =
that this is rather late, but it=E2=80=99s also true that I don=E2=80=99t =
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=E2=80=99m sympathetic to the argument about trouble-shooting the =
network, but not so much to the argument about keeping records.  I=E2=80=99=
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:=20
>=20
> -  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=E2=80=99s =
network.=20

> -  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=E2=80=99re =
storing away the entire (encrypted) content of the TLS session. On the =
other hand you can=E2=80=99t 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=E2=80=99m not even talking about TLS proxy =
firewalls. I=E2=80=99m talking about so-called =E2=80=9CSSL offload=E2=80=9D=
 gateways such as F5=E2=80=99s 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=E2=80=99ll be happy to help you write a draft.

Yoav