Ted Thank you for your response which appears to be an objective attempt to
1. Understand what some of our issues are. 2. Try to suggest optimal solutions. Both long and short term. This type of positive/constructive attitude has been missing from the majority of the List exchanges on this topic. I have found that frustrating. I think the Enterprises involved want to find the best solutions possible and doing this proactively through IETF, in as much a Standards based fashion as possible, seems much better to us than waiting several years and then reacting with custom solutions, as has occurred in the past. I believe this is why Enterprises are making an attempt to work with IETF. I hope the IETF wants this as well. I have several responses to your suggestions below. But rather than take up more list time and attempt to describe in writing some of the issues, I believe there would be with a couple of your suggestions, I think it might be swifter and clearer to have you speak live (and draw pictures, etc. ☺), with a couple of the EDCO people. I would gladly be one of these. Just so you know where I personally come from. I am a SPLUNK admin, so I am a big Endpoint advocate. However, I know from this experience that Endpoint will NOT get us all that we need. Hence my interest in this very important topic. Please let me know what you think. Thanks again Mike From: Ted Lemon [mailto:mel...@fugue.com] Sent: Saturday, July 15, 2017 12:19 PM To: Ackermann, Michael <mackerm...@bcbsm.com> Cc: Dobbins, Roland <rdobb...@arbor.net>; IETF TLS <tls@ietf.org>; Matthew Green <matthewdgr...@gmail.com> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael <mackerm...@bcbsm.com<mailto: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." The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
