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

On Mon, Jul 24, 2017 at 10:03:28AM -0400, Brian Sniffen wrote: > Ted Lemon writes: > > > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL > > wrote: > >> What I am trying to avoid is the ability to *surreptitiously* subvert a > >> protocol that’s

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

> On Jul 24, 2017, at 16:27, Paul Turner wrote: > > > It's fascinating that people cannot seem to stop picking at the scab > remaining after draft-green. I really think we'd be wiser to just let the > wound heal. (And get on with the work that this WG has been

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

On Mon, Jul 24, 2017 at 10:33 AM, Paul Turner wrote: > > > Of course, this is precisely the point. All your proposal does is > complicate the process of sharing sessions with a third-party: it doesn't > stop an endpoint from surreptitiously doing evil. > > > > Is the objective

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

Of course, this is precisely the point. All your proposal does is complicate the process of sharing sessions with a third-party: it doesn't stop an endpoint from surreptitiously doing evil. Is the objective to have the protocol prevent an endpoint “surreptitiously doing evil”? Also, can

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

Kyle Rose writes: > On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen wrote: > >> I could imagine making the server ECDH share dependent on the >> client ECDH share, plus a local random value. At the end of the >> session, the server discloses that random

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

It's fascinating that people cannot seem to stop picking at the scab remaining after draft-green. I really think we'd be wiser to just let the wound heal. (And get on with the work that this WG has been chartered to do, which does not include wiretapping.) Sorry to ask for this so late in

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

On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen wrote: > Ted Lemon writes: > > > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL < > u...@ll.mit.edu> wrote: > >> What I am trying to avoid is the ability to *surreptitiously* subvert a > protocol

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

Ted Lemon writes: > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL > wrote: >> What I am trying to avoid is the ability to *surreptitiously* subvert a >> protocol that’s assumed to be secure. > > You don't seem to be hearing what I'm trying to

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

.@fugue.com> Date: Sunday, July 23, 2017 at 16:34 To: > "Blumenthal, Uri - 0553 - MITLL" <u...@ll.mit.edu> Cc: > "<tls@ietf.org>" <tls@ietf.org> Subject: Re: [TLS] datacenter TLS > decryption as a three-party protocol > > I did a little bit of rubbe

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

On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL wrote: > What I am trying to avoid is the ability to *surreptitiously* subvert a > protocol that’s assumed to be secure. You don't seem to be hearing what I'm trying to say. What you are proposing is physically

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

and act accordingly. --Felix From: TLS <tls-boun...@ietf.org> on behalf of Ted Lemon <mel...@fugue.com> Date: Sunday, July 23, 2017 at 16:34 To: "Blumenthal, Uri - 0553 - MITLL" <u...@ll.mit.edu> Cc: "<tls@ietf.org>" <tls@ietf.org> Subject: Re: [TLS] d

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

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

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

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

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

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

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

On 7/23/2017 12:37 PM, 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

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

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

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

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 -

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

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

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

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

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

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

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

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

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

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? > >

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

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 requested. Kenny Paterson said about the request:

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

On Thu, Jul 20, 2017 at 08:15:03PM +, Blumenthal, Uri - 0553 - MITLL wrote: > Maybe we are better off just retrofitting RSA-key-transport back > into TLS-1.3? In that case at least the peer could refuse this > method of key establishment, and one could safely assume that if a > peer insists on

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

Maybe we are better off just retrofitting RSA-key-transport back into TLS-1.3? In that case at least the peer could refuse this method of key establishment, and one could safely assume that if a peer insists on that key establishment mechanism, this session will be surveilled? If I had to

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

Colm MacCárthaigh wrote: > > If you maintain that draft-green is Wiretapping, then that is also the > correct term for what is happening today. Today, operators are using a > static key, used on the endpoints they control, to decrypt traffic > passively. The only difference is DH vs RSA, and I

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

On Thu, Jul 20, 2017 at 10:21 AM, Stephen Farrell wrote: > > > > It is odd ... and I'm being deliberately provocative to get at the > > doublethink. It is impossible to consider this mode wiretapping and not > > claim the browsers support it today. Plainly, they do. >

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

On 20/07/17 18:08, Colm MacCárthaigh wrote: > On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell > wrote: > >> On 20/07/17 17:43, Colm MacCárthaigh wrote: >>> that's the term that people keep applying, >> >> That term was appropriate for draft-green as justified in [1]

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

On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell wrote: > On 20/07/17 17:43, Colm MacCárthaigh wrote: > > that's the term that people keep applying, > > That term was appropriate for draft-green as justified in [1] > That's disputed by some folks but it's the correct

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

On 20/07/17 17:43, Colm MacCárthaigh wrote: > that's the term that people keep applying, That term was appropriate for draft-green as justified in [1] That's disputed by some folks but it's the correct term. Claiming that current browsers "support" wiretapping is plain odd to me and not that

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

On Thu, Jul 20, 2017 at 12:44 AM, Salz, Rich wrote: > It’s like saying “all browsers that support TLS support wiretapping > because of the static RSA key exchange.” > > > > It’s a little disingenuous > It sure is! and hyperbolic, but that's the term that people keep applying,

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

It’s like saying “all browsers that support TLS support wiretapping because of the static RSA key exchange.” It’s a little disingenuous ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

and attestation. Cheers, Andrei From: Colm MacCárthaigh [mailto:c...@allcosts.net] Sent: Thursday, July 20, 2017 8:57 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Stephen Farrell <stephen.farr...@cs.tcd.ie>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] d

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

On Wed, Jul 19, 2017 at 11:40 PM, Andrei Popov wrote: > Hi Colm, > > > >- Today browsers do turn on wiretapping support in the normal case. >There's nothing they can do about it, and it works right now. > > This is news to me; which browsers do this (so that I

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

Of Colm MacCárthaigh Sent: Thursday, July 20, 2017 1:05 AM To: Stephen Farrell <stephen.farr...@cs.tcd.ie> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol On Wed, Jul 19, 2017 at 3:50 PM, Stephen Farrell <step

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

On Wed, Jul 19, 2017 at 6:09 AM, Benjamin Kaduk wrote: > As Stephen noted in his presentation, a lot of the proposals for passive > decryption can be seen as trying to turn TLS from a two-party protocol into > a three-party protocol. Which is probably the right way to think

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

On Wed, Jul 19, 2017 at 3:50 PM, Stephen Farrell wrote: > That is a perfect example of the hideous dangers of all of this. > The implication in the above is that browsers would/should turn > on wiretapping support in the normal case. > Today browsers do turn on

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

Just to note that Martin's mail contains specific examples and detailed argument. That should be the lowest bar that needs to be met in this discussion, not the arm-waving about "TLS as a DoS attack" or "what about grandma" nonsense that we heard today. The contrast between such non-argument and

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

On 19/07/17 18:45, Colm MacCárthaigh wrote: > For example, browser's > incognito modes may refuse to support such sessions, if they knew what was > going on. That is a perfect example of the hideous dangers of all of this. The implication in the above is that browsers would/should turn on

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

Am 19.07.2017 um 22:32 schrieb Martin Rex: Martin Rex wrote: There were a few issues with F5 loadbalancers (that were just forwarding traffic, _not_ acting as reverse proxy) related to a borked F5 option called "FastL4forward", which occasionally caused the F5 box to truncate TCP streams (the

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

> I find this a very bizarre outcome that works against our collective goals. > If there is no mechanism at all, then it is quite likely that organizations > will use static-DH or stay on TLS1.2. Those are bad options, in my opinion, > because there's no signaling or opt-in to the client. We

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

Martin Rex wrote: > > There were a few issues with F5 loadbalancers (that were just forwarding > traffic, _not_ acting as reverse proxy) related to a borked F5 option called > "FastL4forward", which occasionally caused the F5 box to truncate TCP streams > (the box received 5 MByte of TCP data

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

I just watched the presentation on static DH / TLS decryption in Enterprise settings of todays TLS session https://youtu.be/fv1AIgRdKkY?t=4473 and I'm seriously appalled by the amount of cluelessness in the Networking & IT Departments on the one hand, and by what seems like woefully inadequate

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

e.com> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon <mel...@fugue.com<mailto:mel...@fugue.com>> wrote: The problem is that the actual solution to this problem is t

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

On Wed, Jul 19, 2017 at 10:55 AM, Ted Lemon wrote: > Sorry, the more I think about how to do this in a way that doesn't make > things worse, the less faith I have that it is possible. But if you know > of a way to do it, I certainly don't oppose you doing it. I'm not an >

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

Sorry, the more I think about how to do this in a way that doesn't make things worse, the less faith I have that it is possible. But if you know of a way to do it, I certainly don't oppose you doing it. I'm not an expert: the fact that I don't see how to do it doesn't mean it can't be done.

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

On Wed, Jul 19, 2017 at 10:38 AM, Ted Lemon wrote: > The problem is that the actual solution to this problem is to accept that > you aren't going to be able to decrypt the streams, and then figure out > what to do instead. Which is work the proponents of not doing that are >

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

The problem is that the actual solution to this problem is to accept that you aren't going to be able to decrypt the streams, and then figure out what to do instead. Which is work the proponents of not doing that are not interested in doing, understandably, and which is also not the work of this

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

On 19/07/17 17:58, Benjamin Kaduk wrote: > On 07/19/2017 11:49 AM, Stephen Farrell wrote: >> >> On 19/07/17 14:09, Benjamin Kaduk wrote: >>> As Stephen noted in his presentation, a lot of the proposals for passive >>> decryption can be seen as trying to turn TLS from a two-party protocol >>>

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

On 19/07/17 14:09, Benjamin Kaduk wrote: > As Stephen noted in his presentation, a lot of the proposals for passive > decryption can be seen as trying to turn TLS from a two-party protocol > into a three-party protocol. Which is probably the right way to think > about it, even when all (three)

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

> On Jul 19, 2017, at 6:02 PM, Yoav Nir wrote: > > At the very least, a standards-track multi-party protocol like that can be > something that standards like PCI, HIPAA and others can latch on to and say > “Do TLS 1.3 without backdoors unless you really need to and in

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

> At the very least, a standards-track multi-party protocol like that can be > something that standards > like PCI, HIPAA and others can latch on to and say “Do TLS 1.3 without > backdoors unless you really > need to and in that case use *this*”. > That is better guidance than “Do TLS 1.3

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

> On 19 Jul 2017, at 17:07, Blumenthal, Uri - 0553 - MITLL > wrote: > This is exactly right. We have a real problem here. We should really solve it. We should do the math. :) >>> >>> Is there appetite to do this work? If we restrict this to two paths,

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

>>> This is exactly right.   We have a real problem here.   We should really >>> solve it.   >>> We should do the math.   :) >> >> Is there appetite to do this work? If we restrict this to two paths, one of >> which is >> spending years designing and implementing a new multi-party security >>

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

Am 19.07.2017 um 15:51 schrieb Kyle Rose: On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon > wrote: This is exactly right. We have a /real/ problem here. We should /really/ solve it. We should do the math. :) Is there appetite to do this

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

On Wed, Jul 19, 2017 at 4:02 PM, Ted Lemon wrote: > Bear in mind that what we (or at least I) want out of not publishing a > spec is that this technology not be present by default in TLS > implementations. If someone wants to maintain a set of patches, there's > not much we

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

Bear in mind that what we (or at least I) want out of not publishing a spec is that this technology not be present by default in TLS implementations. If someone wants to maintain a set of patches, there's not much we can do about it, and I don't honestly care *because* there isn't much that we can

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

On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon wrote: > This is exactly right. We have a *real* problem here. We should > *really* solve it. We should do the math. :) > Is there appetite to do this work? If we restrict this to two paths, one of which is spending years

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

This is exactly right. We have a *real* problem here. We should *really* solve it. We should do the math. :) On Wed, Jul 19, 2017 at 3:09 PM, Benjamin Kaduk wrote: > As Stephen noted in his presentation, a lot of the proposals for passive > decryption can be seen as

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

As Stephen noted in his presentation, a lot of the proposals for passive decryption can be seen as trying to turn TLS from a two-party protocol into a three-party protocol. Which is probably the right way to think about it, even when all (three) parties are within the same administrative domain.