> On 8 Jul 2017, at 18:39, Tony Arcieri <basc...@gmail.com> wrote: > > I was one of the people arguing my hardest against the BITS Security proposal > to continue to (ab)use RSA static keys to allow passive MitM, even though TLS > 1.3 had already moved forward on what I would call a more modern protocol > design of the sort I believe payments companies should embrace to improve > their security. > > That said, if people do want to MitM themselves, I would rather there be a > single, easily detectable and very explicit way of doing so, as opposed to > sketchy, incompatible, ad hoc mechanisms.
But all the MITM solutions, whether proxies or static DH are not easily detectable. Client-side proxies - the kind deployed by enterprises - are visible to clients (by the CA signing the proxy certificates) but not to the servers. This is implemented on the server, but is invisible to the client. Even if the client rapid-fires several handshakes to see if the public key does not change, this is indistinguishable from the optimization of using the same key-pair for several seconds (without saving the private key). > Furthermore, it would be nice to have a clear answer for these users, less > they continue to make (bad) arguments that there is something fundamentally > wrong with the design of TLS 1.3 that makes it incompatible with "industry > requirements". > > Clearly there are echoes of the scary protocols of yesteryear, i.e. > Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the > image header you will discover he is quite familiar with these things, and my > personal presumption would be he is not displaying this image to show his > undying love of the Clipper chip, although perhaps he's an especially crafty > and duplicitous NSA sleeper agent. It’s not about the reputations or motivations of the impressive list of authors. It’s about having the capability built into widely used products and libraries. Suppose you have an Internet-facing server with TLS 1.2 and an ECDSA certificate and all supported ciphersuites are ECDHE-ECDSA.Suppose further that your server is using the ever popular Apache/modssl/openssl stack. If you want to disable forward secrecy you have to either replace the certificate with an RSA certificate and move to all static RSA ciphersuites, or you need to replace your stack with something that does what this draft describes. With this draft widely implemented it’s just a matter of turning the capability on. We can’t really stop people implementing it, It’s not detectable by the client and an implementation would seem to be fully compliant with TLS 1.3. And I don’t know how to implement this in such a way that it would work for “good” purposes but not for “bad” purposes, however one defines good and bad here.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
