On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael <mackerm...@bcbsm.com> wrote:
> Your first sentence illustrates the disconnect between the Enterprise > perspective and what many at IETF are saying. > > That being the unencrypted stream is available to the endpoints. IT IS > NOT. When you run a packet trace at the endpoint, you will see > encrypted payloads and will need the keys to decrypt. > > So you can collect packet trace information at thousands or nodes, or you > can collect packet traces from network taps. You still need the keys to > derive meaningful diagnostic and monitoring information. > I agree that we have illustrated the disconnect here, in some sense. However, from my perspective, what I see is that there is a problem: you need to be able to look inside the stream. I think we agree that this is the problem. There is a further problem: you have a set of tools that solves this problem in a particular way, and for the moment, you are stuck with those tools. This is where I think the disconnect starts. I am not disagreeing with you that, for the moment, you are stuck with these tools.m But, I *am* disagreeing with you on the conclusion that this situation leads to. To me, it leads to the conclusion that you need two things. First, you need a plan for how to survive the situation you're stuck in right now. Second, you need a plan for how you're going to approach this when next you upgrade your infrastructure. If I were in your position, my plan for the first part would be to use TLS 1.2. You already have what you want, and you control the endpoints. If it ain't broke, why fix it? What I think is urgent, though, is that you be planning for how you're going to handle this going forward. There are a number of ways of doing it. One way would be to keep an appropriately-scaled log of keys. If you just need to look at active streams, it would be a rolling log, and your snooping device would, when asked to snoop a stream, get the key. This is an improvement over TLS 1.2, because it increases accountability: you have to ask for a key to decrypt a particular conversation, so it is known that you decrypted that conversation. Of course, if you are decrypting _every_ conversation, that's not so great. Of course, key exfiltration is an attack surface, but so is the static key. Better get that right. The other thing you can do is to do proper tooling on your servers, so that you *can *access the raw stream. This would require different tooling than you have now, but there's no technical barrier to doing it. Now, it's possible that either of these solutions would be less secure than using a static key. But I don't hear you arguing that. You're still back on tactics: how do I do what I need to do with the tools I have. The answer is, use TLS 1.2 until you upgrade. Put the time in to shave off all the attack surfaces from your TLS 1.2 installations that TLS 1.3 shaves off--disable the deprecated algorithms, for example. It's your site, you control the endpoints, this shouldn't be a problem. But basically, just keep doing what you are doing for now. Maybe this is a naive suggestion on my part, but what I haven't been hearing in this discussion is serious consideration of the tactical problem and the strategic problem. What I've been hearing is "forget about strategy, we want tactics."
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
