> > 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 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 <sch...@eff.org> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
