-----Original Message----- From: Tom Ritter [mailto:t...@ritter.vg] Sent: Thursday, July 20, 2017 11:20 To: Paul Turner <ptur...@equio.com> Cc: Yoav Nir <ynir.i...@gmail.com>; IETF TLS <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's hum? On 20 July 2017 at 10:07, Paul Turner <ptur...@equio.com<mailto:ptur...@equio.com>> wrote: > 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. Anything's possible, but it there's a difference between: "I demand you implement a new mechanism to securely ship me crypto keys or plaintext, do something for which there is no standard mechanism or agreement." and "If you flip this existing setting right here in OpenSSL, and stick this public key right here, it will automatically satisfy our requirements." Thanks for this clarification. I agree that anything is possible in both directions. Russ opened this discussion by asking about an alternative to static DH. In this model, I’ve assumed the client would need to explicitly opt-in by including an extension in its ClientHello. There are obviously details to work out but if it were possible to provide a method like that, it seems like it would thwart the second option. Would it? I recall one of the arguments that Apple made against the FBI was that they were asking them to do something novel that required significant amounts of work, testing, had never been done before, etc. IANAL but I think this is standard argument to show the request is unreasonable and overly burdensome. Removing that argument concerns me. (US-centric view if that isn't apparent.) -tom
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
