Re: [TLS] Industry Concerns about TLS 1.3

[Yoav Nir <[e-mail]>]

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 <[e-mail]> 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