Re: [TLS] Is there a way forward after today's hum?

[Stephen Farrell <[e-mail]>]

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.