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

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.


Andrew Kennedy
Senior Program Manager, BITS

TLS mailing list

Reply via email to