Ah, I get what you’re saying. DH parameter reuse for performance reasons is not a good thing, and it is not something recommended in the TLS RFCs. But offering standardized ways of exporting/importing keys for wiretapping/surveillance/discovery/analysis purposes is quite different. If a browser were to support this, I would want to avoid using such a browser.
Industry or corporate standards could define key import/export/escrow methods, and certainly SW vendors may choose to support them. At the IETF, IMHO, we can better contribute by focusing on key protection, non-exportability and attestation. Cheers, Andrei From: Colm MacCárthaigh [mailto:c...@allcosts.net] Sent: Thursday, July 20, 2017 8:57 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Stephen Farrell <stephen.farr...@cs.tcd.ie>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol On Wed, Jul 19, 2017 at 11:40 PM, Andrei Popov <andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote: 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)? Like I said, all of them. I don't know of a single browser that forces DH-only and insists on unique DH parameters today, and it wouldn't be practical. So if we're going to refer to an operator who has the server's private key using their own key to decrypt traffic as wire-tapping, then in those terms currently all browsers have support for that turned on, as it's part of existing versions of TLS. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
