On Oct 24, 2017, at 3:04 PM, David A. Cooper <david.coo...@nist.gov> wrote: > In order for a middlebox to be able to use this draft to intercept traffic > that is TLS protected, it would need to: > > 1) get the server to agree to allow it to intercept the traffic; and > > 2) get the client to include the new extension in its ClientHello. > > How would the middlebox get the client to include the extension.
Block all TLS connections that don't use it. >> I believe I know why people want this now. They are worried that if TLS 1.3 >> goes out without something like this, then the market (standard widely >> available browsers) will not implement it. Let me assure you that this isn’t >> an issue. The extension would *never ever* make it to the MUST state, and >> the browsers would be unlikely to ever implement it anyway. > > I partially agree with this and partially disagree. I agree that browsers > (and other similar clients) would be unlikely to ever implement it. I > disagree with the suggestion that proponents of this draft want for browsers > to implement this or want it to be a MUST. Proponents of this draft are > interested in visibility within the data center, and have no interest in > using this capability in any scenario in which a browser would be the client. Let's be clear. While I may have made some statements about the balance of concern over who pays for this, nobody is saying that the proponents of this draft intend a nefarious use of this extension. The concern is not that BCBS is going to invade my privacy. It is that if BCBS gets its way, someone _else_ will use this technology to invade my privacy, or to trojan horse some malware onto my computer, or some other attack. > So, given your agreement that browsers would be unlikely to ever implement > this extension, how would the in-flight WiFi (or other middlebox) be able to > get clients to include the extension if the software they are using doesn't > support it? It seems that the only way would be to coerce the clients into > using a browser (or other client) provided by the attacker (i.e., in order to > use the Internet while in flight you must install Evil Airline's > browser/app). But then, if the attacker is able to get the client to install > and use its own software, then it would easily be able to intercept all > traffic from the client, not just traffic to cooperating servers, so why > would it bother using this draft at all in this case? You've inverted the chain of causality here. The chain is (to the best of my ability to explain it, anyway): 1. Standardize this extension 2. Someone with a service people want to use starts blocking connections that don't enable it. 3. Browser vendors are forced to implement it, or end users are forced to download special browser software. 4. Now an attack surface exists on the user's machine that hadn't previously existed. 5. The user's machine is now subject to attack by a larger set of attackers than it had been previously, using a larger set of attacks than were available previously. None of this is a smoking gun. If everybody keeps all the plates spinning, we won't have a problem. The problem is that everybody keeping the plates spinning is something that pretty much doesn't happen in the real world, as we've seen if we follow the news. And some of the everybodies in this equation are operating infrastructure that we really, really need to be well protected. And others are being stalked. And still others are trying to do secure transactions online. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
