Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

["David A. Cooper" <[e-mail]>]

With this extension, any middlebox anywhere can drop traffic that is not tappable.  Regardless of who controls the clients and servers, we are now enabling entities to block traffic unless you acquiesce. For example, an inflight wifi could use this.  Maybe, ultimately, many/most of the servers that the passengers connect to will not support it, but some might.

Rich,

You've brought up this example of in-flight WiFi and other middleboxes on the Internet uses this extension as a means of coercing individuals into allowing their TLS traffic with servers to be intercepted, but I fail to see how the scenario is at all realistic.

Yes, any box that sits between the client and the server can drop traffic for whatever reason it wants. Such a box could today drop any traffic that is protected using TLS.

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. You previously https://mailarchive.ietf.org/arch/msg/tls/dmXNd4dh_Ul8S1-P6mvMNbZjCAw" rel="nofollow">said:

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.

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?