Re: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt

Hi, Thank you for your comments. 2017-07-19 7:05 GMT+02:00 Ilari Liusvaara : > On Wed, Jul 19, 2017 at 05:42:24AM +0200, Kazuho Oku wrote: >> Hi, >> >> I am happy to see us having discussions on how to protected SNI. I am >> also happy to see that draft-huitema-tls-sni-encryption [1] proposes >>

[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.

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 trying to turn TLS fr

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 designing and implement

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 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 can do about it, and

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 work? If we restrict

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 17, 2017 12:29 PM, "Roland Dobbins" wrote: On 17 Jul 2017, at 21:11, Watson Ladd wrote: How do you detect unauthorized access separate from knowing what > authorization is? > I think we're talking at cross purposes, here. Can you clarify? You said you need to look at packets to see un

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

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, one of >>> which is

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Wed, Jul 19, 2017 at 7:48 AM, Watson Ladd wrote: > > On Jul 17, 2017 12:29 PM, "Roland Dobbins" wrote: > > On 17 Jul 2017, at 21:11, Watson Ladd wrote: > > How do you detect unauthorized access separate from knowing what >> authorization is? >> > > I think we're talking at cross purposes, here

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

You said you need to look at packets to see unauthorized access. How do you that access is unauthorized unless the authorization system is doing the monitoring? Over the years I've met with businesses who have these kinds of set ups. The way it usually works is that the analysis is secondary

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 without

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Wed, Jul 19, 2017 at 9:26 AM, Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > > Same question. At some point in time you need to decide to start examining > all the traffic. At that point you can start capturing its plaintext. The > proposed alternative seems to be capturing the ciphe

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 that case use > *this*”.

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) p

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 19, 2017, at 18:35, Colm MacCárthaigh wrote: > > That's not what I've seen. Instead, I see administrators creating port > mirrors on demand and then filtering the traffic they are interested in using > standard tcpdump rules, and I see MITM boxes that selectively decrypt some > traf

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

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 >> into a three-party protocol. Which is probably the ri

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

The hum told us that the room was roughly evenly split. In hind sight, I wish the chairs had asked a second question. If the split in the room was different for the second question, then I think we might have learned a bit more about what people are thinking. If a specification were available

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

>> That's not what I've seen. Instead, I see administrators creating port >> mirrors on demand and then >> filtering the traffic they are interested in using standard tcpdump rules, >> and I see MITM boxes >> that selectively decrypt some traffic to look inside it and apply some kind >> of secur

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

Provably involved, or involved setting an evil bit? On Wed, Jul 19, 2017 at 7:10 PM, Russ Housley wrote: > The hum told us that the room was roughly evenly split. In hind sight, I > wish the chairs had asked a second question. If the split in the room was > different for the second question, t

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

On 19/07/17 18:10, Russ Housley wrote: > The hum told us that the room was roughly evenly split. In hind > sight, I wish the chairs had asked a second question. If the split > in the room was different for the second question, then I think we > might have learned a bit more about what people ar

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

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] draft-green-tls-static-dh-in-tls13-01

> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL > wrote: > > My point is that if you own/control the endpoint, then it doesn’t matter from > the architecture point of view It absolutely matters from an operational perspective, which both informs and is informed by the architectu

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 > not interested in d

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 19, 2017 10:43 AM, "Dobbins, Roland" wrote: > On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL wrote: > > My point is that if you own/control the endpoint, then it doesn’t matter from the architecture point of view It absolutely matters from an operational perspective, which b

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 19, 2017, at 19:48, Watson Ladd mailto:watsonbl...@gmail.com>> wrote: Technical solutions to political problems are not the right approach. --- Roland Dobbins mailto:rdobb...@arbor.net>> ___ TLS mailing list TLS

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. On

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 > expert: the fact tha

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 19, 2017, at 19:15, Blumenthal, Uri - 0553 - MITLL > wrote: > > Or are you simply trying to delay the inevitable? I'm open to any solution which meets the stated requirements & is deployable & usable on real-world production networks, without necessitating a total redesign of said

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

> It seems like we would be rejecting a good opportunity to make what the > network operators want work in a better and more secure way, while making it > harder for passive observers and coercive authorities, to use the same > mechanism for other purposes. What do we gain? beyond a hollow moral

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> Or are you simply trying to delay the inevitable? I'm open to any solution which meets the stated requirements & is deployable & usable on real-world production networks, without necessitating a total redesign of said networks & the complete social reorganization of the ent

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 19, 2017, at 20:06, Blumenthal, Uri - 0553 - MITLL > wrote: > > most of them already carry all that’s necessary (and more) to perform > surveillance from inside the endpoint. Unfortunately, this is not the case. Quite the opposite, actually. It's already been explained why endpoi

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On Jul 19, 2017, at 20:06, Blumenthal, Uri - 0553 - MITLL > wrote: > > It’s not the networks that need to be “totally redesigned”, but the mechanism > to do surveillance. You underestimate the cascade effect of such measures. It's neither operationally nor economically viable.

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 19, 2017 10:54 AM, "Dobbins, Roland" wrote: On Jul 19, 2017, at 19:48, Watson Ladd wrote: Technical solutions to political problems are not the right approach. --- Roland Dobbins ___ TLS mailing list TLS@iet

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> most of them already carry all that’s necessary (and more) to perform surveillance from inside the endpoint. Unfortunately, this is not the case. Quite the opposite, actually. It's already been explained why endpoint-based measures are impractical. If they were pract

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 19 Jul 2017, at 20:29, Watson Ladd wrote: Now it turns out that the requirements on solutions came from organizational issues you never told us about. The organizational issues have been described previously, both on the list and in the meetings; and the technical issues are quite separate

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 19 Jul 2017, at 20:37, Blumenthal, Uri - 0553 - MITLL wrote: I keep telling that this pool is drying up. The organizations who need this the most are already working in all-crypto environments. Nothing about that pool is going to change. --- Roland Dobbin

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

So is it an accurate assessment that the reason you aren't using ipsec fur this use case is that the APIs suck and your engines don't support them? On Jul 19, 2017 8:41 PM, "Roland Dobbins" wrote: > On 19 Jul 2017, at 20:37, Blumenthal, Uri - 0553 - MITLL wrote: > > I keep telling that this pool

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 19, 2017 11:38 AM, "Roland Dobbins" wrote: On 19 Jul 2017, at 20:29, Watson Ladd wrote: Now it turns out that the requirements on solutions came from > organizational issues you never told us about. > The organizational issues have been described previously, both on the list and in the m

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

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&ACKed 5 MByte of TCP dat

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 can

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

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 wireta

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 t

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 wiretapping support in the normal

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 about it, > even when

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

Ted, if we use a new extension, then the server cannot include it unless the client offered it first. I am thinking of an approach where the server would include information needed by the decryptor in the response. So, if the client did not offer the extension, it would be a TLS protocol viola

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

The agenda included: - Data Center use of Static DH (30 min) https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ - National Cybersecurity Center of Excellence (NCCOE) project for visibility within the datac

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

I think that's okay, since this is only for use in applications where both parties are in on the deal. But the problem with the static ecdh proposal is the the server is not compelled to reveal that it is doing it. On Jul 20, 2017 8:01 AM, "Russ Housley" wrote: > Ted, if we use a new extension,

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

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 can avoid using them)? Thanks, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Colm

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

> On 20 Jul 2017, at 8:01, Russ Housley wrote: > > Ted, if we use a new extension, then the server cannot include it unless the > client offered it first. I am thinking of an approach where the server would > include information needed by the decryptor in the response. So, if the > client 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 can avoid using > them)? >