I use an airplane as an example of a “captive” population, substitute any similar group you want.
* 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. True, but that’s not the point. The point is by adding this extension into the clientHello, we are providing middleboxes with another knob to control traffic. I think we want to avoid that. And keep in mind it’s not just HTTP, but *any* TLS-using traffic, such as many VPN’s. It wouldn’t necessarily enable spying, but it could be used to guarantee that all traffic is amenable to spying. As for how would such clients get promulgated? Some simple scenarious include “surf for free on your flight, but use our Chromium-based browser to do so, available for free here.” How many people on the plane would click and download? > 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. How do you propose to guarantee that? As Stephen pointed out, we have no way to prevent this from “escaping” on to the public Internet, and no way to prevent captive audiences from being forced to comply.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
