-----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 20, 2017 07:54 To: Paul Turner <paul.tur...@venafi.com>; Ted Lemon <mel...@fugue.com> Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's hum? On 20/07/17 12:44, Paul Turner wrote: > > I believe Russ was outlining a method where an extension would be > added to TLS 1.3 that would provide for delivery of a decryption key > to a third party during the handshake (correct me if I got that wrong, > Russ). Because it would be during the handshake, it would seem to be > visible to the TLS Client—in fact, the client would have to include > the extension to begin with. If the TLS client saw the extension and > did not consent, it could abort the connection. If the TLS Server were > attempting to provide access to the exchanged data to a third party, > it would seem they could use 1, 2, or 3 above and not have to go to > the trouble of attempting to subvert the mechanism that Russ proposes > (and others have previously proposed). Yeah, good try, but *which* third party? Let’s use the oppressive government institution that I believe you’ve mentioned (pardon me if I got that wrong) with a connection over the Internet in this case. Can you reply in that context? I’m truly interested in understanding. It wasn’t a “try”. The kind of (IMO) intractable questions that Would arise include whether or not enterprise clients only want their own snoopers to snoop and not everyone else's? And then the naming issues become intractable. And of course in many applications (e.g. SMTP) there's still >1 TLS session in the mail e2e path. And in the web there can be >1 box between the browser and content site. Yoav already brought up another one about about:config, and, and, and... In the end, this'd be another failed proposal is my bet. I volunteer to help in the engineering of that if needed;-) That's not to doubt or deride the folks posing illformed requirements but because squaring circles is just not a good plan. S.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
