-----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Tom Ritter Sent: Thursday, July 20, 2017 10:44 To: Yoav Nir <ynir.i...@gmail.com> Cc: IETF TLS <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's hum? On 20 July 2017 at 01:53, Yoav Nir < <mailto:ynir.i...@gmail.com> ynir.i...@gmail.com> wrote: > > On 20 Jul 2017, at 8:01, Russ Housley < <mailto:hous...@vigilsec.com> > 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. It seems like that problem exists today with TLS 1.3. If a government is powerful enough to mandate key escrow, wouldn’t they also be power enough to mandate implementing static DH with TLS 1.3 (so that they key escrow is possible). In addition, based on this level of influence, couldn’t they alternatively require TLS server owners to provide them unencrypted data. -tom _______________________________________________ TLS mailing list <mailto:TLS@ietf.org> TLS@ietf.org <https://www.ietf.org/mailman/listinfo/tls> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
