On 20 July 2017 at 10:29, Paul Turner <paul.tur...@venafi.com> wrote: > Thanks for this clarification. I agree that anything is possible in both > directions. Russ opened this discussion by asking about an alternative to > static DH. In this model, I’ve assumed the client would need to explicitly > opt-in by including an extension in its ClientHello. There are obviously > details to work out but if it were possible to provide a method like that, > it seems like it would thwart the second option. Would it?
Not when the target of the request is Facebook for their Messenger App. Or Google for the Gmail app, or Hangouts. Or Skype. What percentage of TLS protected communication takes place between a client and server developed by the same company? All of that is immediately at risk. What about 360 Browser (one of the popular Chinese-made web browsers)? Hell, they _still_ aren't validating SSL certificates!![0] The dynamic for them (both technical and political) is quite different than for what we tend to think of as 'browsers'. I get the impression you're assuming that 'the' (for nebulous values of 'the') government isn't going to ask a web browser to support the mechanism, and they would only go to the webservers. But because it's an offer/accept mechanism, there's an argument that goes "Hey Browser-Maker make all of your installs _offer_ to encrypt to our escrow key, and if the server doesn't accept it, don't." "Hey US-Company, make all of your web servers support escrowing to our key if the client offers to. If the client doesn't offer, don't." The more I think about standardizing such a mechanism the more nervous I get we will be building something that is too likely to be used, even if not expansively, against the ideals we have espoused in 2804 and elsewhere. -tom [0] Yea. Really. It was this case a little bit ago for 99% of sites on the web and I'll make you a bet it's still the case today. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
