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

[Ted Lemon <[e-mail]>]

On Jul 11, 2017, at 2:39 PM, Steve Fenter <[e-mail]> wrote:
> Network security monitoring is not just monitoring traffic that results from communications with customers and partners.  All it takes is for one user to click on a phishing email and there is malware inside the enterprise.  Once this happens, TLS becomes the enemy, because 30% of malware is TLS encrypted, and any TLS features intended to thwart payload inspection work against the enterprise.

I realize that you are making a substantive comment here and might not welcome a sales pitch, but FWIW there are ways of addressing this that don't involve examining each stream, and are likely as effective.   E.g., malicious domain redirect based on the domain name in the URL.   This is a lot cheaper than doing decryption and inspection of the contents of every TLS stream.   It also allows for other methods than payload analysis for detecting probably malware—e.g., pattern analysis.   I'm pretty sure that Stephen will tell you that this is an attack as well, and he's not wrong, but it has the virtue of not requiring that TLS be broken.

Also, please note that the proposal you are referring to does not solve this problem at all, unless the malware is already on a server on your network (which is the scenario you are describing).   If that's the case, why is TLS intercept the most cost effective way to detect this malware?   It seems to me that it would be a lot easier to just scan the file on the server before making it available for download.

Can you explain why that's not the right solution for this particular use case?

Also, although there was a lot of talk about how you need to do decryption-and-inspection rather than using proxies for performance, that actually just doesn't make sense.   Is it because the proxy is too close to the edge, resulting in trombone routes?   Otherwise I don't see how it could possibly be more efficient to decrypt and eavesdrop than to proxy.   Can you explain?

Sorry to hold your feet to the fire, but what you are saying here just doesn't make sense to me.

As for threat detection, again I'm not seeing how decryption and packet analysis is a win here.   Can you explain?

I see why it's helpful for troubleshooting, although again a proxy would take care of that.   But in any case, for the other two examples, it doesn't make sense even from a performance perspective.