Hi Steve, Thanks for taking the time to detail out your concerns and current use cases. This is helpful.
On Tue, Jul 11, 2017 at 9:39 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 12 July 2017 at 09:59, Steve Fenter <steven.fente...@gmail.com> wrote: >>> And if you had one an estimate for how much malware does it's own >>> obfuscation or home-grown crypto in addition or instead of using TLS. >>> The reason to ask is that as soon as malware does that then you >>> are back to analysis based on ciphertext only. From descriptions >>> of advanced attack schemes, they do seem to do both when calling >>> home or exfiltrating data. In which case I think your argument >>> falls. >> >> I don't have any numbers for home-grown crypto. I would think the odds are >> better for the enterprise if they can decrypt and inspect whatever portion >> is TLS. > > Wouldn't malware avoid connecting to servers that offer the wrong > credentials? Implementing elementary key pinning or overriding trust > anchors is pretty trivial - it's a feature that enterprises frequently > rely on after all. It sounds like for malware, we could do something to better document your security options as well as monitoring. While the documentation is there for key pinning and trust anchors, this might not be obvious to network managers - what RFC to look at and how they fit together. The points Stephen, Ted, Martin have made are good. A TLS overview document with an appendix of use cases might be a good start to help fill this gap for operators. Even if it isn't published, we could figure out wiki space or something like wikipedia to make sure it's available to operators. If the start of this documentation looks like it will generate new work developing alternate ways to accomplish the goals while maintaining the integrity of TLS, a new WG could even be an option. For malware, the proposed solution (Matt Green draft) isn't a great fit as the server side won't be managed within your enterprise to allow for the decryption described in the proposal. For the other parts of your original message that were snipped from this thread, I have a few questions/comments to see how we might be able to narrow the scope and clarify a few things. For the Troubleshooting description, could redefining the end point of the server work as terminating at a load balancer to help with at least some of your use cases? For the threat detection and security analytics, I know a number of current products rely on the ability to TLS. The primary concern here would be the remote server not managed by the enterprise. TLS 1.3 prevents this from being possible and the proposed draft doesn't help, so I think it would be best to figure out a way forward for this use case either with the help of MILE (incident responders) or others. Currently products use proprietary methods to accomplish this task (at least some do). For DDoS, the experts say they can work with fingerprints of encrypted streams, so it's other attack types that may require some thinking through of options. I'm happy to chat about that as I've done a lot of work in incident response and know of others that may be able to assist as well. I'm still reading through messages and drafts on this topic, so this message should not be read as a position on either side, but more to narrow the scope if possible and think through what is being requested and why - so it is clarified. Thanks. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Best regards, Kathleen _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
