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
- 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 <bitssecur...@fsroundtable.org>
> 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
> - 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.
TLS mailing list