Subject: Re: [TLS] Industry Concerns about TLS 1.3

From: BITS Security <[email-masked]>
Date: Mon, 3 Oct 2016 20:45:38 +0000

> > 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:[email-masked]] 
Sent: Tuesday, September 27, 2016 2:30 PM
To: BITS Security <[email-masked]>
Cc: [email-masked]
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 also implies the ability to decrypt others' sessions.

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.

--
Seth Schoen  <[email-masked]>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107

---

From: BITS Security <[email-masked]>
Date: Mon, 3 Oct 2016 21:21:08 +0000

> 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:[email-masked]] 
Sent: Tuesday, September 27, 2016 4:17 PM
To: BITS Security <[email-masked]>
Cc: Peter Bowen <[email-masked]>; [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <[email-masked]> wrote:
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).

Hello again,

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

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.

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?

-- 
Tony Arcieri

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 3 Oct 2016 17:37:46 -0400

> 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 dec…

This may be less than an ideal requirement.

Malware wants to do three things (with some hand waiving): (1) spread,
(2) collect data, and (3) egress data. I think Step (1) and intrusion
detection is a worthy cause, but not at the cost of breaking the
secure channel.

Perhaps it would be better to focus on (2) and (3). (2) can be tricky
based on how deeply the malware is burrowed in. (3) is much easier
since the malware needs to open a socket.

Policies for (3) are really just whitelist/blacklist approaches. I'm
guessing egress points are wide open at the moment, and the PCI
requirement is fostering blacklists and causing the organization to be
reactive. If the egress points are closed at the organizational
boundary, then the organization is proactive and using a whitelist
approach.

Would it be possible to have the PCI folks re-examine their position
since it seems to be boxing BITS members into something untenable?

Jeff

---

From: Watson Ladd <[email-masked]>
Date: Mon, 3 Oct 2016 14:46:32 -0700

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

Surely you remember the day when all SWIFT provided devices had to be
replaced thanks to some fun in the random number generators. Then there is
POISON NUT.

The Shadow brokers leak included tools to extract VPN keys from Cisco
routers. TJ Maxx involved breaking WEP.

> 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).
>
> Hello again,
>
> 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 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.
>
> 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.
>
> 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?
>
> --
> Tony Arcieri
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 3 Oct 2016 15:51:48 -0700

On Mon, Oct 3, 2016 at 2:21 PM, BITS Security <[email-masked]
> wrote:

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

This is simply not true. In 2015 the PCI council was pushing for updating
to TLS 1.1+ in short order, but backed off out of "industry concerns"
similar to the ones you are voicing here, and have delayed the mandatory
rollout of TLS 1.1 until 2018.

That's at least two years away.

After that, they will deprecate TLS 1.1. That will probably take at least a
year. So in 2019 (again, pure speculation as to the earliest time this will
possibly happen), TLS 1.2 will be mandatory.

After that, they may deprecate TLS 1.2 if it is demonstrated to be
insecure. There is no reason to suspect at this point that that will even
happen. TLS 1.2 is generally recognized as secure, and the "LTS" profile
should fix whatever low-priority security concerns remain.

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

That is absolutely not true. The PCI's motivation for TLS version upgrades
has been real-world security vulnerabilities, and again, it took them 15
years to deprecate TLS 1.0.

There is absolutely no evidence that the PCI council plans on making TLS
1.3 mandatory any time soon, and if we follow a version-a-year cadence
(which they're NOT presently working on, based on the one deprecation data
point we have it's ~3 years per version) it will be 2020 at the earliest
before it happens.

You are asking the IETF to make a serious compromise regarding the security
of the Internet based on *pure speculation*. A minimum degree of due
diligence here would be to first ask the PCI council what their plans for
mandating TLS 1.3 actually are, and if they *actually* give you a date that
scares you, that might be a reason to voice concern so late in the process.

I think what you're proposing is actively harmful to Internet security and
you should be working with the PCI Council, not the IETF, to address your
concerns.

-- 
Tony Arcieri

---

From: Florian Weimer <[email-masked]>
Date: Wed, 05 Oct 2016 20:16:27 +0200

* Hubert Kario:

> those secret keys are on the client machines and they will stay on client 
> machines
>
> making it hard to extract master key from process memory is just security 
> through obscurity, not something that will stop a determined attacker

I think extracting the master key is probably not what you want to do
anyway, just adding Systemtap probes to get cleartext copies
(preferably along with connection detail information) should be
sufficient.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 05 Oct 2016 20:17:27 +0200

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

---

From: BITS Security <[email-masked]>
Date: Wed, 5 Oct 2016 19:37:46 +0000

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:[email-masked]] 
Sent: Wednesday, October 5, 2016 2:17 PM
To: BITS Security <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

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

---

From: Sean Turner <[email-masked]>
Date: Tue, 11 Oct 2016 20:24:49 -0400

As one of the WG chairs, it looks like it’s time to bring to a close whether or not we’ll be re-introducing static RSA key exchange.

One digression before that though: I think there is a realization in the IAB, IESG, and many parts of the IETF that significant operational/management issues exist with encryption; the MaRNEW workshop [0][1][2], some related drafts [3][4], and the PLUS/ACCORD BOFs proposals are just some examples that reflect this.

On dropping static RSA key exchange: The DH-only key exchange proposal had a very lengthy and robust discussion.  PFS was definitely a driver [5], but the simplifying effect of removing static RSA key exchange was another one that should not be forgotten; less options, less code, (hopefully) less coding errors.  It is probably also worth pointing out that the "remove RSA key exchange" shoe has been dropping since 2003: “RSAES-OAEP is recommended for new applications; RSAES-PKCS1-v1_5 is included only for compatibility with existing applications, and is not recommended for new applications” [6].

On the one hand, I am sympathetic to concerns about impacts resulting from protocol changes.  On the other hand, the cycle of new protocol version followed by product updates is not really that out of the ordinary; this cycle is disliked by those with budgets but normal nonetheless.  Also, there appears to be a couple of different solutions that would allow an enterprise to do what it wants.  I’m not seeing anything that would alter the consensus that we reached earlier to drop static RSA key exchange from TLS 1.3.

spt

[0] https://www.iab.org/activities/workshops/marnew/
[1] https://datatracker.ietf.org/doc/draft-nrooney-marnew-report/
[2] https://www.ietf.org/proceedings/94/slides/slides-94-saag-1.pdf
[3] https://www.ietf.org/archive/id/draft-mm-wg-effect-encrypt-03.txt
[4] https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-management/
[5] https://datatracker.ietf.org/doc/rfc7525/
[6] https://datatracker.ietf.org/doc/rfc3447/

> On Oct 05, 2016, at 15:37, BITS Security <[email-masked]> wrote:
>