On 20 July 2017 at 01:53, Yoav Nir <ynir.i...@gmail.com> wrote: > > On 20 Jul 2017, at 8:01, Russ Housley <hous...@vigilsec.com> wrote: > > Ted, if we use a new extension, then the server cannot include it unless the > client offered it first. I am thinking of an approach where the server > would include information needed by the decryptor in the response. So, if > the client did not offer the extension, it would be a TLS protocol violation > for the server to include it. > > > So we also add an alert called “key-export-needed” in case the client does > not include it. > > That way a browser (as an example) can show the user why the connection was > broken (“server requires wiretapping to be enabled. Go to about:config if > that is OK and change the allow-wiretap setting to True”)
I previously expressed that I could support the extension mechanism - I'm sympathetic to regulatory requirements and unhappy with, although understanding of, what has become the 'standard mechanism' (breaking crypto) to achieve them. I've looked at more than one 'end to end' encrypted messenger that tosses in the 'third end' of key escrow. But to suggest such a mechanism might ever be implemented in a web browser throws my hackles up. The discussion has always been about datacenter - the people concerned say "We don't want your datacenter stuff in our protocol and the proponents say "No really, we only care about the datacenter." The concerns around some future government-mandated key escrow is very real and very concerning. -tom _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
