Adding Andrei Popov.
From: BITS Security <bitssecur...@fsroundtable.org>
Sent: Thursday, September 22, 2016 1:13:45 PM
To: Yuhong Bao; firstname.lastname@example.org
Subject: RE: Industry Concerns about TLS 1.3
Yuhong-Thank you for the response.
Our thinking here is that enterprises who use content delivery networks will
have the end-user session hidden from them.
The session from the end user to the edge of the content delivery network will
be a different session than the one from the enterprise sees. The IP's and
ports will be different, the TCP layer activity like retransmissions will be
different, and because of caching the application layer will be somewhat
different. There will be times when we need packet level data from the End
User and TLS decryption of this packet level data for troubleshooting.
With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt
it with the RSA private key. With TLS 1.3 we will have to rely on the
SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available.
Unfortunately, Microsoft does not allow this functionality, which is a problem
in a TLS 1.3 only environment.
From: Yuhong Bao [mailto:yuhongbao_...@hotmail.com]
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security <bitssecur...@fsroundtable.org>; email@example.com
Subject: Re: Industry Concerns about TLS 1.3
This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657
From: TLS <tls-boun...@ietf.org> on behalf of BITS Security
Sent: Thursday, September 22, 2016 10:19:48 AM
Subject: [TLS] Industry Concerns about TLS 1.3
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
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
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
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
- 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.
Senior Program Manager, BITS
TLS mailing list
TLS mailing list