On Sun, Jul 9, 2017 at 2:04 AM, Colm MacCárthaigh <c...@allcosts.net> wrote:
> > On Sat, Jul 8, 2017 at 9:27 AM, Watson Ladd <watsonbl...@gmail.com> wrote: >> >> > They also don’t want to install TLS proxies all over the place. That’s >> a >> > large extra expense for them. >> >> Nginx exists. What's the blocker? > > > Here's how these networks work today: > > * Key servers are configured to use RSA KX, no DH. > * In some cases, all outbound (e.g. internet) connectivity is also proxied > via such a server. Clients are made to trust a private CA for this purpose. > * All data is not necessarily logged or stored somewhere, and almost > certainly not in the plain, as that would increase over-all risk. > * Admins use port-mirrors and tools like tcpdump to investigate/scan > suspicious flows from time to time, or as part of a targeted investigation. > Occasionally it might also be used for debugging. The RSA keys can be used > to render the connections plain on demand. > * That doesn't mean that the RSA private keys are readily available, they > are often very tightly controlled. > > Migrating to proxies would: > > * Be a very big operational change. Gotta get nginx on all of the boxes, > is that even possible? > That's an oversimplification - proxying traffic should require addition of points in the middle, but shouldn't (always) require modification of the source and destination points. But yes, it would be a big operational change. I don't think the folks arguing that proxies can handle this are suggesting it's trivial to migrate in this direction. > * Completely change the access mechanisms, invalidate almost all of the > operational controls. > Why wouldn't these be improvements? (More below.) > * Probably more than double the basic compute costs associated with > encryption. > Perhaps, but also probably more than doubles the cost to attackers, by granting forward secret properties to internal traffic and by removing the number of places where keys exist that are capable of decrypting this data. * Create more sensitive environments where plaintext is floating around. > I don't see how that follows. In a previous message, Jacob Hoffman-Andrews included a great description of why it should reduce the amount of access to sensitive keys that can produce plaintext: I would also point out that retrospectively decrypting pcaps asks TLS to do double duty: as at-rest encryption in addition to transit encryption. If, instead, each TLS server shares a copy of its plaintext via a TLS connection to an encrypted storage service, the enterprise gets much better security properties. Not only does it retain forward secrecy for in-datacenter traffic, it can control the keys for at-rest data much more tightly. Instead of every TLS frontend having the keys for retrospective decryption, those keys can be limited to auditors or security team members. > That doesn't mean that these vendors/operators are owed a solution, or an > easy-to-insert more-or-less-compatible-with-today mechanism. But it does > help assess whether they are really likely to adopt TLS1.3 to begin with. > That's quite fair. However, what's so far been unstated is that it's plausible for regulatory pressure to eventually build to push regulated enterprises towards TLS 1.3 and away from 1.2. It's also quite plausible that regulatory pressure could eventually build to push agencies to use encrypted traffic with forward secret properties within their data centers, for the same reasons that it's unacceptable today to send plaintext around. This WG is responsible for making the strongest protocol possible, and it's up to the rest of the world how to use it. TLS 1.3 looks likely to be extremely widely used on the public internet. If enterprises end up staying behind on TLS 1.2 inside their networks, or making their own non-standard alternative, because they can't summon the will to get away from network-based monitoring, they're likely to face costs for doing that eventually, whether regulatory or just in the ongoing overhead of creating and maintaining non-standard tools. -- Eric > -- > Colm > > _______________________________________________ > 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
