On Fri, Jul 7, 2017 at 4:04 PM, Russ Housley <hous...@vigilsec.com> wrote: > > The enterprise wants forward secrecy on the public Internet. Terminating > the TLS session at the load balancer preserves forward secrecy on the > public Internet. >
> In your response, you ignored a fairly significant point in my previous > post. > > In some industries, there are regulatory requirements that cannot > be > met without access to the plaintext. Without some authorized > access > mechanism, the enterprise will be forced to use plaintext within > the > datacenter. That seems like a worse alternative to me. > > From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating > outdated crypto, like RC4 or MD5. Instead, it is using exactly the same > crypto algorithms and key sizes as draft-ietf-tls-tls13. Again, this seems > like a much better way forward than plaintext throughout the datacenter. > Your response is also failing to address a very important point, by presenting the choice as either static-key TLS or plaintext. That's clearly not the case -- you can maintain traffic visibility at endpoints within your data center, by forcing traffic through terminating trusted proxies which log the same network traffic data you would get from passive monitoring. You can do that with forward secret TLS today. I'm sure it's not as easy to change your designs to incorporate proxies as it is to just rely on the network monitoring infrastructure you already have in place, but that's not a good enough reason to insist that the TLS WG standardize an RFC which can plainly be used for wiretapping. It's also passing up an opportunity to gain the benefits of forward secret connections within your data center, which should really be a best practice and requirement for any organization managing data that merits strict regulatory oversight. This comes across as asking the IETF to contort itself around its own stated goals so that the enterprise doesn't have to do any heavy lifting to keep up with security trends. As explained so far, this seems like something the TLS WG should reject. -- Eric > > Russ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
