> On Oct 24, 2017, at 3:17 PM, Ted Lemon <mel...@fugue.com> wrote: > > 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.
...with the assumption that a client would automatically revert to trying the connection with the visibility extension if it can't make a connection without the extension. Why would that assumption be useful? How is this situation different than the current practice of using HTTP if HTTPS fails? > >>> 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. Can you demonstrate how such an attack would work without the assumption that a client (e.g., browser) would, as policy, downgrade to using the extension if it can't connect without the extension. I understand the general concern. > >> 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. I still don't see how step 2 is different than forcing a connection without using TLS at all? Why is the visibility extension more dangerous than only allowing connections with no TLS? > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
