Hi Colm,
* Today browsers do turn on wiretapping support in the normal case. There's nothing they can do about it, and it works right now. This is news to me; which browsers do this (so that I can avoid using them)? Thanks, Andrei From: TLS [mailto:[email protected]] On Behalf Of Colm MacCárthaigh Sent: Thursday, July 20, 2017 1:05 AM To: Stephen Farrell <[email protected]> Cc: <[email protected]> <[email protected]> Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol On Wed, Jul 19, 2017 at 3:50 PM, Stephen Farrell <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
