Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Ilari Liusvaara
On Thu, Jul 20, 2017 at 08:42:10PM +, Blumenthal, Uri - 0553 - MITLL wrote: > On 7/20/17, 16:32, "ilariliusva...@welho.com on behalf of Ilari Liusvaara" > wrote: > > Maybe we are better off just retrofitting RSA-key-transport back > > into TLS-1.3? > > This has in fact been requ

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Blumenthal, Uri - 0553 - MITLL
Ilari, I got your point. But in view of the request this WG is discussing now, I see only two reasonable (IMHO) opinion: 1. Tell those requestors to go away because TLS 1.3 has been designed to always be forward-secure; or 2. Add a *detectable* non-PFS key exchange so those requestors would h

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Ted Lemon
I did a little bit of rubber-duck debugging on this proposal with Andrea on the way back from Boston this morning. It's actually better for the server to secretly use a static key than to negotiate. Stephen has already explained why: if this is a negotiation, then it's possible for a third p

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Blumenthal, Uri - 0553 - MITLL
I think there's no way the connection can be established if the third party in control of the network does not allow that. My only goal here is to leave fewer possibilities to set the eavesdropping silently. Regards, Uri Sent from my iPhone > On Jul 23, 2017, at 10:33, Ted Lemon wrote: > >

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Stephen Farrell
On 23/07/17 13:43, Blumenthal, Uri - 0553 - MITLL wrote: > Ilari, > > I got your point. > > But in view of the request this WG is discussing now, I see only two > reasonable (IMHO) opinion: 1. Tell those requestors to go away > because TLS 1.3 has been designed to always be forward-secure; or 2

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Blumenthal, Uri - 0553 - MITLL
I'd be perfectly happy with TLS 1.3 having nothing but PFS, and those in need of the plaintext getting it from the endpoint OOB. Regards, Uri Sent from my iPhone > On Jul 23, 2017, at 12:16, Stephen Farrell wrote: > > > >> On 23/07/17 13:43, Blumenthal, Uri - 0553 - MITLL wrote: >> Ilari, >

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Ted Lemon
On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL wrote: > I think there's no way the connection can be established if the third party > in control of the network does not allow that. This is why it’s hard to reason well about this stuff—we tend to get the threat models wrong. Th

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Christian Huitema
On 7/23/2017 12:37 PM, Ted Lemon wrote: > On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL > mailto:u...@ll.mit.edu>> wrote: >> I think there's no way the connection can be established if the third >> party in control of the network does not allow that. > > This is why it’s hard to r

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Ted Lemon
On Jul 23, 2017, at 5:37 PM, Christian Huitema wrote: > Speaking of threat model, one of the main threats is the "Lavabit" case: a > server is asked to somehow implement a backdoor so existing clients. In that > case, it is very useful for clients to detect that something has changed. > They ca

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Jeffrey Walton
On Sun, Jul 23, 2017 at 5:37 PM, Christian Huitema wrote: > ... > Speaking of threat model, one of the main threats is the "Lavabit" case: a > server is asked to somehow implement a backdoor so existing clients. In that > case, it is very useful for clients to detect that something has changed. >

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Blumenthal, Uri - 0553 - MITLL
On Jul 23, 2017, at 15:37, Ted Lemon wrote: > On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL > wrote: >> I think there's no way the connection can be established if the third party >> in control of the network does not allow that. > > This is why it’s hard

Re: [TLS] datacenter TLS decryption as a three-party protocol

2017-07-23 Thread Felix Wyss
How about requiring a record of a fixed size that either contains the session key encrypted with a “leaking key” or the output of a stream cipher keyed with the session key. A 3rd party observer would not be able to determine whether the session key is being leaked but the client can tell and a