Re: [TLS] Industry Concerns about TLS 1.3

[Hugo Krawczyk <[e-mail]>]

If the problem is the use of forward secrecy then there is a simple
solution, don't use it.
That is, you can, as a server, have a fixed key_share for which the secret
exponent becomes the private key exactly as in the RSA case. It does
require some careful analysis, though.

But maybe I misunderstood the problem and maybe I should not be putting
these surveillance-friendly ideas in people's minds...

Hugo




On Thu, Sep 22, 2016 at 1:19 PM, 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> -  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.
>
> Sincerely,
>
> Andrew Kennedy
> Senior Program Manager, BITS
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>