> On Oct 24, 2017, at 3:23 PM, Salz, Rich <rs...@akamai.com> wrote: > > 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?
Just to make sure I understand, in this scenario the special-purpose browser could just as easily, today, be a browser with no TLS at all? That is, I don't see why this scenario is specific to the visibility extension. > > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
