On Wed, Jul 19, 2017 at 3:50 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> That is a perfect example of the hideous dangers of all of this. > The implication in the above is that browsers would/should turn > on wiretapping support in the normal case. > Today browsers do turn on wiretapping support in the normal case. There's nothing they can do about it, and it works right now. If static-DH is permitted, and I don't mean if we release a document describing it, I mean if we don't forbid static DH parameters; this will also continue to be the case. My take: I think we should forbid static DH for this reason. Next, if proxies are deployed as the mechanism, this will also continue to be the case. Again, nothing a browser can do, and I argue that real-world security is left much much worse for users too. On the other hand, if we standardize a signaled, opt-in, mechanism; then browsers have more fine-grained options. I suspect that browsers would NOT support this by default, just as they don't accept private CAs by default. Instead the browser would have to configured per a corporate policy. But they could /also/ choose to disable incognito mode in such circumstances, to be more fair to end-users. It's an example of something that can't be done today at all. Such a mode is likely fine for the corporate users and what they want, but is not so useful for intelligence agencies and so on, precisely because its signaled and a bit more transparent. In real world terms, I would regard it much /less/ likely to create the kind of MITM infrastructure that's useful for that case. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
