Re: [TLS] datacenter TLS decryption as a three-party protocol

[BITS Security]

> It seems like we would be rejecting a good opportunity to make what the 
> network operators want work in a better and more secure way, while making it 
> harder for passive observers and coercive authorities, to use the same 
> mechanism for other purposes. What do we gain? beyond a hollow moral victory.

+1 and this is fundamentally why we’ve made significant effort to work within 
the IETF process.  We strongly believe a consensus outcome will be better for 
all, including those who are currently in disagreement.  What we’d like to 
avoid is being told the solution is to ignore (or admire) the problem.  Finding 
a workable solution will reduce the risk of forking TLS and will increase the 
broad adoption of 1.3.

-Andrew



From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Colm MacCárthaigh
Sent: Wednesday, July 19, 2017 1:45 PM
To: Ted Lemon 
Cc:  
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol



On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon 
> wrote:
The problem is that the actual solution to this problem is to accept that you 
aren't going to be able to decrypt the streams, and then figure out what to do 
instead.   Which is work the proponents of not doing that are not interested in 
doing, understandably, and which is also not the work of this working group.

I'm skeptical that there is a way for this working group to solve the proposed 
problem, but if there is, it involves figuring out a way to do this that 
doesn't make it easy to MiTM my connections, or, say, those of activists in 
dangerous places.

I find this a very bizarre outcome that works against our collective goals. If 
there is no mechanism at all, then it is quite likely that organizations will 
use static-DH or stay on TLS1.2. Those are bad options, in my opinion, because 
there's no signaling or opt-in to the client. We can do much better than that.  
Client opt-ins are far from academic. For example, browser's incognito modes 
may refuse to support such sessions, if they knew what was going on.

It's also bad if organizations end up deploying static-DH and that means we 
can't do things like checking for changing DH parameters.

It seems like we would be rejecting a good opportunity to make what the network 
operators want work in a better and more secure way, while making it harder for 
passive observers and coercive authorities, to use the same mechanism for other 
purposes. What do we gain? beyond a hollow moral victory.

--
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

Florian--Anecdotally, I have heard Microsoft and F5 did code upgrades a few 
years back that moved Diffie Hellman to the top cipher suite priorities which 
broke security and fraud monitoring, APM reporting, and sniffer troubleshooting 
for a financial services client and at least one other organization in a 
different industry.  

The solution, at the time, was to put the PFS options (choices we will no 
longer in 1.3) at the bottom of the priority list.  I don't know how much of 
this was communicated back to the vendors at the time.  

In retrospect, this could have been seen as the canary in the coalmine... but 
here we are now at least.  

- Andrew 


-Original Message-
From: Florian Weimer [mailto:f...@deneb.enyo.de] 
Sent: Wednesday, October 5, 2016 2:17 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

* BITS Security:

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

We should have already seen this with changing defaults in crypto libraries as 
part of security updates.  That should have broken passive monitoring 
infrastructure, too.

Maybe some of the vendors can shed some light on this problem and tell us if 
they ever have received pushback for rolling out ECDHE-by-default.  (I know 
that some products have few capabilities for centralized policy management, 
which is why defaults matter a lot
there.)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

> I work firsthand enforcing these requirements at a payments company. Again, I 
> do not speak on behalf of my employer.   
> It wasn't until last year that PCI decided to deprecate TLS 1.0, at the time 
> a 16 year old standard. I think your sense of emergency is highly 
> over-exaggerated.   
> I find it highly unlikely that any group such as the PCI Council will begin 
> mandating TLS 1.3 any time soon. I would go as far as to call your concerns 
> "imaginary".  

If PCI has mandated upgrading TLS because of vulnerabilities, they are likely 
to do it again and in fact have provided strong hints to the market where they 
should be beyond the minimum requirement itself.  I don't see that the timing 
really matters because it isn't based on the age of the standard, it is based 
on the standard becoming outdated.  We're trying to get ahead of foreseeable 
problem some will have. 

Further, PCI does not require TLS encryption at all in a private data center, 
at least not technically.  However, in practice they strongly recommend 
segmenting the Cardholder Data Environment, which I suspect most financials 
have done, and many have used TLS as part of their strategy for segmentation 
(encrypted PCI traffic flowing through devices does not bring these devices 
into scope for audit).  So according to current practice, auditors are going to 
require certain levels of TLS in order for our segmenting strategies to work.

> If you are worried about such an eventuality, the IETF is the wrong place to 
> complain. It is far, far too late in the TLS 1.3 process to be voicing these 
> concerns. Where were you 2+ years ago when it was the appropriate time in the 
> TLS development cycle to voice such concerns? I think the view of more 
> "forward thinking" payments companies is TLS 1.3 has taken too long already, 
> and they would like to start deploying it in its current form and would 
> prefer unnecessary holdups/distractions which have already occurred 
> throughout the process.

PCI requirement providing Intrusion Detection at the entrance to Cardholder 
Data Environments as well as at critical points inside the Cardholder Data 
Environment.  Intrusion Detection requires decryption of TLS.  For some large, 
complex organizations this can be a large number of physical inspection points, 
more than can be accommodated by MITM.  I understand this may not be a problem 
for your current environment but others do not have that luxury.

> That said, there is still plenty of time to ensure that groups like the PCI 
> Council do not put in place requirements which would affect the centralized 
> traffic-decrypting MitM-capability on your payments stack. Perhaps you should 
> be voicing your concerns there? If you are worried about a TLS 1.3 mandate 
> preventing your MitM capability, the onus is on you to convince the relevant 
> payments standards bodies that mandating TLS 1.3 is a bad idea for the 
> payments industry. I think those organizations are better poised to judge 
> whether such an approach reflects on necessary requirements versus pervasive 
> antipatterns among complacent companies unprepared for the future and ripe 
> for a data breach.

We can implore PCI all we want, but if events overtake us, such as the 
introduction of new security risks, we have to be prepared for eventualities 
like TLS 1.3 being the mandate and must be prepared perform IDS/IPS routines at 
scale such an environment.

> In the meantime, you have disclosed a veritable treasure map to a 
> traffic-decrypting single point of failure which ostensibly exists at all of 
> the companies you represent which attackers could leverage to recover all 
> payment credentials. That sounds like a huge security threat.
> Would you mind disclosing which companies you represent, so I can ensure for 
> the safety of my own money that I do not use them?

I don't know how this listserv operates in practice but it is this type of 
sophistry that hard boils my eggs to put it politely.  Perhaps this is just the 
regular cost of participation but that would be unfortunate.  

If you look at the industry reports like the Verizon PCI Breach and Compliance 
Reports, private keys simply aren't being stolen.  Maybe there is an outlier or 
two but there certainly isn't a documented trend I can find.  If you have 
contravening information to provide I am all ears. 

- Andrew 



From: Tony Arcieri [mailto:basc...@gmail.com] 
Sent: Tuesday, September 27, 2016 4:17 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: Peter Bowen <pzbo...@gmail.com>; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <bitssecur...@fsroundtable.org> 
wrote:
The PCI DSS is already requiring TLS 1.2 for financial institutions that 
participate in the Payment Card Industry.  .BANK (exclusiv

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

> > The various suggestions for creating fixed/static Diffie Hellman keys raise 
> > interesting possibilities.  We would like to understand these ideas better 
> > at a technical level and are initiating research into this potential 
> > solution.  We need to understand the potential ramifications and other 
> > implementation details.  This solution would have to be implemented in 
> > servers, firewalls, load balancers, Internet proxies, and mainframes.  If 
> > vendors broadly refuse to support then it is not much a solution but at 
> > this point looks like it is worth exploring.  

> Bear in mind that, if you do that, anyone who gets a copy of that secret will 
> be able to retrospectively decrypt all of your organization's TLS traffic.  
> However, that's presumably true of any solution that satisfies the 
> requirement that you describe: there will always be _some_ secret that the 
> organization possesses that, if obtained by an adversary, would let the 
> adversary retrospectively decrypt traffic.

We can put private keys in an HSM and implement other processes to protect 
them.  This is what some are doing with RSA today.  If you look at the Verizon 
breach report and other similar resources, breaches from stolen network packets 
and/or stolen private keys is not a discernible trend (though I will cede past 
results don't predict future performance). 

> This configuration might be a bit dangerous because it means that "servers, 
> firewalls, load balancers, Internet proxies, and mainframes"
would all possess the information needed to decrypt _each other's_ traffic, so 
someone inside or outside the organization who can steal that information can 
then read all of the traffic, even traffic that was originated by devices they 
don't know about or have a relationship to.
> So organizational unit X can read the traffic of organizational unit Y, even 
> if X wasn't meant to be in a supervisory or audit relationship over Y, 
> because the ability to emit decryptable traffic of this kind also implies the 
> ability to decrypt others' sessions.

We've heard this a different way, for example not every layer of the data 
center would have the same key or that key is always available. I have to admit 
to some ignorance here which is why we want to explore this potential option.  
Even if it works (which it might not as you say) there still is the question of 
if vendors would being willing to support.  

> It also provides a way that other parties outside of the organization can, 
> even through passive eavesdropping, recognize the organization's traffic as 
> associated with that organization -- kind of like a global cookie inside the 
> TLS handshake.  People could use that to target surveillance or advertising 
> even if they didn't know or recognize the organization's IP address ranges.

Something else important to check on that could undermine this solution.  
Appreciate it.  

- Andrew 




-Original Message-
From: Seth David Schoen [mailto:sch...@eff.org] 
Sent: Tuesday, September 27, 2016 2:30 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

BITS Security writes:

> The various suggestions for creating fixed/static Diffie Hellman keys raise 
> interesting possibilities.  We would like to understand these ideas better at 
> a technical level and are initiating research into this potential solution.  
> We need to understand the potential ramifications and other implementation 
> details.  This solution would have to be implemented in servers, firewalls, 
> load balancers, Internet proxies, and mainframes.  If vendors broadly refuse 
> to support then it is not much a solution but at this point looks like it is 
> worth exploring.  

Bear in mind that, if you do that, anyone who gets a copy of that secret will 
be able to retrospectively decrypt all of your organization's TLS traffic.  
However, that's presumably true of any solution that satisfies the requirement 
that you describe: there will always be _some_ secret that the organization 
possesses that, if obtained by an adversary, would let the adversary 
retrospectively decrypt traffic.

This configuration might be a bit dangerous because it means that "servers, 
firewalls, load balancers, Internet proxies, and mainframes"
would all possess the information needed to decrypt _each other's_ traffic, so 
someone inside or outside the organization who can steal that information can 
then read all of the traffic, even traffic that was originated by devices they 
don't know about or have a relationship to.
So organizational unit X can read the traffic of organizational unit Y, even if 
X wasn't meant to be in a supervisory or audit relationship over Y, because the 
ability to emit decryptable traffic of this kind als

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

Ilari - I understand yours (and others) view on this but there is no technical 
reason why this couldn't be part of the standard.  A potential solution, like 
many cipher suite *choices* in past versions of TLS, would be optional and up 
to both clients and servers to configure what they are willing to support (or 
not support).  You appear to be assuming everyone is running off the same set 
of requirements (one-size-fits-all) and we are here to tell you that isn't 
necessarily true.  

- Andrew




-Original Message-
From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] 
Sent: Tuesday, September 27, 2016 2:24 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: Eric Rescorla <e...@rtfm.com>; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Tue, Sep 27, 2016 at 06:07:28PM +, BITS Security wrote:
> Hi Eric--Thank you for the prompt.  
> 
> Our requirements are for the same capabilities we have today with TLS 
> 1.2, namely to be able to take a trace anywhere in our enterprise and 
> decrypt it out of band (assuming that we own the TLS server).  This 
> includes traces taken from physical taps, traces from span or mirror 
> ports, traces from the virtual environment, and/or traces from agents 
> on workstations.  We need to be able to apply a key to sniffer 
> devices, security and fraud monitoring tools, APM devices, and/or TLS 
> decryption appliances.

No changes to standards are going to happen to make that any easier.
Don't waste your time.


-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

The various suggestions for creating fixed/static Diffie Hellman keys raise 
interesting possibilities.  We would like to understand these ideas better at a 
technical level and are initiating research into this potential solution.  We 
need to understand the potential ramifications and other implementation 
details.  This solution would have to be implemented in servers, firewalls, 
load balancers, Internet proxies, and mainframes.  If vendors broadly refuse to 
support then it is not much a solution but at this point looks like it is worth 
exploring.  

Really appreciate those who brought this to our attention.  

- Andrew



From: hugok...@gmail.com [mailto:hugok...@gmail.com] On Behalf Of Hugo Krawczyk
Sent: Thursday, September 22, 2016 7:41 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

Hi Eric--Thank you for the prompt.  

Our requirements are for the same capabilities we have today with TLS 1.2, 
namely to be able to take a trace anywhere in our enterprise and decrypt it out 
of band (assuming that we own the TLS server).  This includes traces taken from 
physical taps, traces from span or mirror ports, traces from the virtual 
environment, and/or traces from agents on workstations.  We need to be able to 
apply a key to sniffer devices, security and fraud monitoring tools, APM 
devices, and/or TLS decryption appliances.  

Outbound TLS today requires an MITM/proxy solution in order to decrypt TLS.  
One visibility point only in this environment is not adequate to cover every 
situation especially in a crisis (whether a broken app or a more nefarious 
concern like APT).  

- Andrew



From: Eric Rescorla [mailto:e...@rtfm.com] 
Sent: Friday, September 23, 2016 4:43 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: Salz, Rich <rs...@akamai.com>; nalini.elk...@insidethestack.com; 
tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Andrew,

What would probably be most helpful here would be if you tried to describe what 
you think your requirements are in some sort of protocol-neutral fashion.

-Ekr


On Fri, Sep 23, 2016 at 1:31 PM, BITS Security <bitssecur...@fsroundtable.org> 
wrote:
Rich (et al.) -- I understand where you are coming from but I will poke a 
little bit at this portrayal.

We are not here hat-in-hand asking for a return to RSA key exchange to the 
proposed standard.  We do however want to raise our concern (and hopefully your 
awareness) of what appears to be an unintended consequence of the move to 
PFS-only choices.

What is happening from our perspective is choice is being removed and an 
adequate replacement has (seemingly) not been identified.  This lack of choice 
may not affect everyone and every use-case but it will predictably affect 
large, complex, highly regulated enterprises in a serious manner.  This is a 
classic case of security requirement being in conflict with a different 
security requirement.

IETF protocols are run extensively both on the public Internet and within 
private enterprises.  Any decisions made by the TLS Working Group will affect 
both environments, and the needs and requirements of both environments should 
be considered.

-Andrew


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

> It would be very interesting to get the network diagnostic and operations 
> people (rather than the architects) of the above companies involved in this 
> conversation.

Nothing has ever stopped them.  Never. Participation is as simple as joining a 
mailing list.  The IETF has been doing SSL and TLS for nearly 20 years.  It is 
not a secret.  It was incumbent on them to reach out and get involved.

> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).

Don't try to equate "listen to each other" with "meet my requirement."  The 
message has been stated, very clearly, from individuals, WG members, through 
document editors and WG chairs and up to Security Directors:  static RSA is not 
coming back to TLS 1.3 .  Since before the last IETF this was the message, 
consistently.  So perhaps you should answer the question first -- why aren't 
*you* listening? :)

PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to 
prevent PFS in their existing deployment?  Why won't additional controls to 
prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So far 
all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to move to 
TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs in TLS 1.3 
too.

Look, pretty much the entire world is being spied on by national-scale 
adversaries who are recording all traffic for eventual decryption and 
correlation.  *Almost everyone* is having their traffic surveilled. The 
problems of debugging a set of enterprise apps doesn’t amount to a hill of 
beans in that world. It just doesn't. Same for a particular industry's 
regulatory requirements.

> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.

Oxygen, coke, and cookies too.

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

Hi Brian--Thanks for the practitioner comment.  

Something perhaps worth mentioning here is that there often isn't just one 
support team inside an enterprise.  There are application support teams for 
each application, network support people, security engineering support people, 
server support people, desktop support people, mainframe support people, packet 
analysis teams.  All of them use different methods, and often each doesn't know 
details about how the other teams work.  Some of these teams do work at the 
endpoints but many gain visibility through other means (at least in the FS 
industry).  

-Andrew 




-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Brian Sniffen
Sent: Saturday, September 24, 2016 11:31 PM
To: nalini.elk...@insidethestack.com; Watson Ladd <watsonbl...@gmail.com>; 
Ackermann, Michael <mackerm...@bcbsm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

nalini.elk...@insidethestack.com writes:

> [ Unknown encryption status ]
> [ Unknown signature status ]
>
>
>
>>>
>>> What I am saying,  in relation to your "Delivering a stable product"  
>>> comment is that over time various industries have learned what it takes to 
>>> "Deliver a stable product".    We did not >>want to invest millions in 
>>> these debugging networks.  But  we learned the hard way,  that it was 
>>> necessary.
>>> I am not a member of the banking coalition that started this subject,  nor 
>>> of the banking industry at all,  but I certainly understand their 
>>> perspective and am concerned about  the same >>unmanageable future they 
>>> described.
>
>>Do  Akami, Cloudlflare and Google magically not have these problems?
> It would be very interesting to get the network diagnostic and 
> operations people (rather than the architects) of the above companies 
> involved in this conversation.

Hi, technical person most directly responsible for incident response and urgent 
debugging here.  We modify endpoints to get what we need.  We did have taps 
that relied on knowing the RSA Kx secret... but haven't used them in about a 
decade.

I think the banks have an answer not available to the global passive
adversaries: modify the server or client to use a fixed ECDH share, then use 
tech much like their current choices.  It'll take a while to develop, but 
nobody in that environment plans to move to TLS 1.3 for operational systems any 
time soon anyway.

-Brian


> Also, you know, companies don't really enjoy spending money on network 
> diagnostic products which might be considered overhead.   So, if they are, we 
> might do them the courtesy of not thinking that they are foolish to do so. 
> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).
> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.
> Nalini
>>
>> Thanks
>>
>> Mike
>>
>>
>>
>> -Original Message-
>> From: Jeffrey Walton [mailto:noloa...@gmail.com]
>> Sent: Friday, September 23, 2016 10:55 AM
>> To: Ackermann, Michael <mackerm...@bcbsm.com>
>> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
>> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>>
>> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
>> wrote:
>>> From the perspective an Enterprise that runs these applications and has 
>>> invested HEAVILY in the debugging networks.
>>>
>>> The reason we are debugging these networks is so that "The 5-6 order of 
>>> magnitude of folks using them"  will have good service.  If they do not,  
>>> they will consider competitors and/or generate a litany service calls or 
>>> complaints.        I.E.    When these "Folks"  are slow or not working they 
>>> are just as unhappy as we are.
>>>
>>
>> Isn't that the market operating as expected? Those who deliver a stable 
>> product at a competitive price are rewarded, while those who fail to deliver 
>> or deliver at an unreasonable cost are not? (Some hand waiving).
>>
>> If all providers failed to deliver or delivered an inferior product, then it 
>> might indicate a major course correction is needed. But I don't think that's 
>> the case here.
>>
>> Jeff
>>
>>
>> The information contained in this communication is highly confidential a

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

Peter- 

Outbound TLS connections require MITM for decryption.  Inbound or internal TLS 
connections can be decrypted with an RSA private key under TLS 1.2. 

The PCI DSS is already requiring TLS 1.2 for financial institutions that 
participate in the Payment Card Industry.  .BANK (exclusive top level banking 
domain) is also planning to require TLS 1.2.   We're anticipating that a 
regulatory body like these will require TLS 1.3 at some point in the future.  
Financial institutions then have to comply if they want to continue to do 
business with the companies represented by the regulatory body (like large 
credit card companies in the case of PCI).

-Andrew




-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: Yaron Sheffer <yaronf.i...@gmail.com>; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 2:10 PM, BITS Security <bitssecur...@fsroundtable.org> 
wrote:
>  we need a better option than TLS 1.2 that will, perhaps sooner than we might 
> expect, be deprecated.

I'm somewhat confused here.  The concern over RSA for key exchange versus DH 
for key exchange would only seem to apply when the network tapping system has 
access to the RSA key, right?  So the part of this about monitoring the network 
for external chat and such doesn't really change if the client is using TLS 1.1 
or 1.3, as you still can't decrypt the connection just from monitoring, right?

If that is true, then it implies that the server is at least somewhat under 
control of the monitor, so it can support TLS 1.2 as long as needed.  TLS 1.0 
came out in 1999 and is still now (in 2016) widely deployed.  While I hope TLS 
1.3 deployment is speedy, I don't forsee browsers dropping TLS 1.2 and earlier 
support any time soon.

Thanks,
Peter
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

> you can keep using TLS1.2 in your internal network, can't you?

There are both public and private sector regulators arcing towards being more 
prescriptive in this area.  It is possible, if not likely, in the not too 
distant future that my member companies will not have the choice to "downgrade" 
to "obsolete" TLS versions.  

Note: the standards track document says it "Obsoletes: RFC 5246" which is TLS 
1.2.  That's a signal that may prove difficult to divert in this rapidly 
evolving threat and regulatory environment.

- Andrew 



From: Xiaoyin Liu [mailto:xiaoyi...@outlook.com] 
Sent: Friday, September 23, 2016 5:00 PM
To: BITS Security <bitssecur...@fsroundtable.org>; Salz, Rich 
<rs...@akamai.com>; nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Andrew,
 
I don't understand why your "choice is being removed", because you can keep 
using TLS1.2 in your internal network, can't you?
 
Best,
Xiaoyin
 
From: BITS Security
Sent: Friday, September 23, 2016 4:31 PM
To: Salz, Rich; nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3
 
Rich (et al.) -- I understand where you are coming from but I will poke a 
little bit at this portrayal.  

We are not here hat-in-hand asking for a return to RSA key exchange to the 
proposed standard.  We do however want to raise our concern (and hopefully your 
awareness) of what appears to be an unintended consequence of the move to 
PFS-only choices.  

What is happening from our perspective is choice is being removed and an 
adequate replacement has (seemingly) not been identified.  This lack of choice 
may not affect everyone and every use-case but it will predictably affect 
large, complex, highly regulated enterprises in a serious manner.  This is a 
classic case of security requirement being in conflict with a different 
security requirement.  

IETF protocols are run extensively both on the public Internet and within 
private enterprises.  Any decisions made by the TLS Working Group will affect 
both environments, and the needs and requirements of both environments should 
be considered.

-Andrew


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3


> It would be very interesting to get the network diagnostic and operations 
> people (rather than the architects) of the above companies involved in this 
> conversation.

Nothing has ever stopped them.  Never. Participation is as simple as joining a 
mailing list.  The IETF has been doing SSL and TLS for nearly 20 years.  It is 
not a secret.  It was incumbent on them to reach out and get involved.   

> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).

Don't try to equate "listen to each other" with "meet my requirement."  The 
message has been stated, very clearly, from individuals, WG members, through 
document editors and WG chairs and up to Security Directors:  static RSA is not 
coming back to TLS 1.3 .  Since before the last IETF this was the message, 
consistently.  So perhaps you should answer the question first -- why aren't 
*you* listening? :)

PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to 
prevent PFS in their existing deployment?  Why won't additional controls to 
prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So far 
all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to move to 
TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs in TLS 1.3 
too.

Look, pretty much the entire world is being spied on by national-scale 
adversaries who are recording all traffic for eventual decryption and 
correlation.  *Almost everyone* is having their traffic surveilled. The 
problems of debugging a set of enterprise apps doesn't amount to a hill of 
beans in that world. It just doesn't. Same for a particular industry's 
regulatory requirements. 

> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.

Oxygen, coke, and cookies too.

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

> 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:watsonbl...@gmail.com] 
Sent: Thursday, September 22, 2016 3:06 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 10:19 AM, BITS Security <bitssecur...@fsroundtable.org> 
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.  Al

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

It's possible to run TLS 1.3 and PFS through the Content Delivery Network and 
into the enterprise data center, and then have a load balancer or other proxy 
terminate TLS.  This gives us the option of running a different protocol in the 
data center, but we need a better option than TLS 1.2 that will, perhaps sooner 
than we might expect, be deprecated.  

-Andrew 

-Original Message-
From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
Sent: Friday, September 23, 2016 3:52 PM
To: BITS Security <bitssecur...@fsroundtable.org>; Watson Ladd 
<watsonbl...@gmail.com>; Ackermann, Michael <mackerm...@bcbsm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

You are implicitly suggesting to remove perfect-forward-secrecy as soon as a 
TLS flow is created by the CDN. However these packets will still be traveling 
over the public Internet and/or "private" (leased, not really
private) MPLS VPNs, where we KNOW that government agencies are eavesdropping 
and recording network flows to keep for years ahead. In other words, even when 
the TLS flow enters "your" network, you and your customer are still at risk 
from pervasive monitoring.

Thanks,
Yaron
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

Rich (et al.) -- I understand where you are coming from but I will poke a 
little bit at this portrayal.  

We are not here hat-in-hand asking for a return to RSA key exchange to the 
proposed standard.  We do however want to raise our concern (and hopefully your 
awareness) of what appears to be an unintended consequence of the move to 
PFS-only choices.  

What is happening from our perspective is choice is being removed and an 
adequate replacement has (seemingly) not been identified.  This lack of choice 
may not affect everyone and every use-case but it will predictably affect 
large, complex, highly regulated enterprises in a serious manner.  This is a 
classic case of security requirement being in conflict with a different 
security requirement.  

IETF protocols are run extensively both on the public Internet and within 
private enterprises.  Any decisions made by the TLS Working Group will affect 
both environments, and the needs and requirements of both environments should 
be considered.

-Andrew


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3


> It would be very interesting to get the network diagnostic and operations 
> people (rather than the architects) of the above companies involved in this 
> conversation.

Nothing has ever stopped them.  Never. Participation is as simple as joining a 
mailing list.  The IETF has been doing SSL and TLS for nearly 20 years.  It is 
not a secret.  It was incumbent on them to reach out and get involved.   

> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).

Don't try to equate "listen to each other" with "meet my requirement."  The 
message has been stated, very clearly, from individuals, WG members, through 
document editors and WG chairs and up to Security Directors:  static RSA is not 
coming back to TLS 1.3 .  Since before the last IETF this was the message, 
consistently.  So perhaps you should answer the question first -- why aren't 
*you* listening? :)

PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to 
prevent PFS in their existing deployment?  Why won't additional controls to 
prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So far 
all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to move to 
TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs in TLS 1.3 
too.

Look, pretty much the entire world is being spied on by national-scale 
adversaries who are recording all traffic for eventual decryption and 
correlation.  *Almost everyone* is having their traffic surveilled. The 
problems of debugging a set of enterprise apps doesn’t amount to a hill of 
beans in that world. It just doesn't. Same for a particular industry's 
regulatory requirements. 

> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.

Oxygen, coke, and cookies too.

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

time various industries have learned what it takes to "Deliver a 
> stable product".We did not want to invest millions in these debugging 
> networks.   But  we learned the hard way,  that it was necessary.
> I am not a member of the banking coalition that started this subject,  nor of 
> the banking industry at all,  but I certainly understand their perspective 
> and am concerned about  the same unmanageable future they described.

Do  Akami, Cloudlflare and Google magically not have these problems?
>
> Thanks
>
> Mike
>
>
>
> -Original Message-----
> From: Jeffrey Walton [mailto:noloa...@gmail.com]
> Sent: Friday, September 23, 2016 10:55 AM
> To: Ackermann, Michael <mackerm...@bcbsm.com>
> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
> wrote:
>> From the perspective an Enterprise that runs these applications and has 
>> invested HEAVILY in the debugging networks.
>>
>> The reason we are debugging these networks is so that "The 5-6 order of 
>> magnitude of folks using them"  will have good service.   If they do not,  
>> they will consider competitors and/or generate a litany service calls or 
>> complaints.I.E. When these "Folks"  are slow or not working they 
>> are just as unhappy as we are.
>>
>
> Isn't that the market operating as expected? Those who deliver a stable 
> product at a competitive price are rewarded, while those who fail to deliver 
> or deliver at an unreasonable cost are not? (Some hand waiving).
>
> If all providers failed to deliver or delivered an inferior product, then it 
> might indicate a major course correction is needed. But I don't think that's 
> the case here.
>
> Jeff
>
>
> The information contained in this communication is highly confidential and is 
> intended solely for the use of the individual(s) to whom this communication 
> is directed. If you are not the intended recipient, you are hereby notified 
> that any viewing, copying, disclosure or distribution of this information is 
> prohibited. Please notify the sender, by electronic mail or telephone, of any 
> unintended receipt and delete the original message without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
> nonprofit corporations and independent licensees of the Blue Cross and Blue 
> Shield Association.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

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.  

-Andrew


From: Yuhong Bao [mailto:yuhongbao_...@hotmail.com] 
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
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 
<bitssecur...@fsroundtable.org>
Sent: Thursday, September 22, 2016 10:19:48 AM
To: tls@ietf.org
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 
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 cha

[TLS] Industry Concerns about TLS 1.3

[BITS Security]

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