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?
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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
