Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security <[e-mail]>]

> Let's get specific about how this works: if an employee of a regulated
> institution is logging into a TLS protected social media website, how
> do you decrypt the connection without using a MITM device on the
> network? I'm sure with large enough checks collaboration application
> providers will be happy to implement whatever you need in the way of
> logging at the server. 

The issue here is not just collaboration applications; it’s also point-to-point messaging protocols.   
  
Some vendors have created p2p messaging services to meet supervision requirements, and these have an explicit man-in-the-middle.   
  
But general-purpose messaging services (and other collaboration services) which don’t have an explicit man-in-the-middle (and don’t permit server-side access to user plaintext and can’t be observed by other means) can’t be used in supervised environments. This rules out many cloud-hosted services today. 
  
In the future, even enterprise-hosted versions of messaging services probably won’t be usable in supervised environments if there’s no way for the enterprise to access traffic except on the destination endpoint.   


> And firing isn't enough of a threat to get people to behave when it
> comes to circumventing monitoring? 

The issue isn’t getting people to behave, or punishing them when they don’t; it’s demonstrating that the business has met its legal obligation to create a record of communications that can be accessed in case of an investigation.  An employee who circumvents controls can be fired, but that does not absolve the business of liability for failing to create a legally required record of the content of that employee’s communications.

- Andrew



-----Original Message-----
From: Watson Ladd [mailto:[e-mail]] 
Sent: Thursday, September 22, 2016 3:06 PM
To: BITS Security <[e-mail]>
Cc: [e-mail]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 10:19 AM, BITS Security <[e-mail]> 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.

You've "recently learned" about a change that was proposed several
*years* ago, starting in the earliest drafts of TLS 1.3. This change is being made due to substantial security issues with encryption based key exchanges: while we could redesign the exchange to repair these issues, the risk of key compromise resulting in decryption of old data is real.

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

Let's get specific about how this works: if an employee of a regulated institution is logging into a TLS protected social media website, how do you decrypt the connection without using a MITM device on the network? I'm sure with large enough checks collaboration application providers will be happy to implement whatever you need in the way of logging at the server.

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

This can be solved by logging the entire connection contents at the endpoint. I don't understand how you say that this is not a
replacement: it's literally the same data as you obtain decrypting the session. This is a requirement that many of the companies involved in the TLS 1.3 process have also, and they haven't complained about it.
Maybe I don't understand what architecture you have which makes this impossible. If you have too much volume, then I don't see how your network appliance doesn't have the same problem. If it's intermittent, and you didn't log verbosely on errors, set up the endpoint to log the next fault, and wait.

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

Browsers haven't even succeeded in killing SSL 3.0 yet. I think you have much more time then you think to stay on TLS 1.2.

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

And firing isn't enough of a threat to get people to behave when it comes to circumventing monitoring?

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

Critical to whom? Not me. If you want to propose a solution that works please do so. But don't pretend your problems are our problems.

Sincerely,
Watson Ladd

>
> Sincerely,
>
> Andrew Kennedy
> Senior Program Manager, BITS
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



--
"Man is born free, but everywhere he is in chains".
--Rousseau.