On 17 Jul 2017, at 16:04, Blumenthal, Uri - 0553 - MITLL wrote:
“But we (the (network) authorities) are the good guys, and we need to break the guarantees TLS provides so we can catch criminals – and here is how we propose to break TLS-1.3”.
The actual concern of intranet operators is the inadvertent breakage of an important mechanism used for troubleshooting and security in the context of TLS-encrypted traffic on their own networks, within their own span of administrative control.
Considering that unless at least one of the end-points chooses to comply with the “rules” it will not work – the claim that this measure is to help the good guys does not sound very candid.
To clarify, this technique is for use on intranets, within a single span of administrative control.
Who is the intended target of this mechanism? What kind of criminals is it supposed to catch/detect? Surely not the malware that penetrated your infrastructure and tries to “call home”?
Actually, it's been used for this very purpose, quite successfully, for many years. It's also used to detect and classify lateral movement and propagation of malware and attacks within an intranet.
And it's used to detect and prevent malware downloads by intranet user populations.
The proponents of the “broken TLS” somehow expect that those criminals would use weakened crypto for the convenience of the ntwork police. How much sense does this make?
In most cases, the attackers don't use any additional crypto at all. When they do, it's most often poor crypto.
Experience shows that criminals use not just cutting edge – bleeding edge crypto.
You're absolutely correct that a few do - as you note, Conficker is a good example of that.
Plus, there are many ways to foil this proposed mechanism – for example, super-encrypting the data before transmission.
Sure. But the ability to infer the presence of superencryption is extremely valuable in and of itself.
Then there’s an issue of the abuses. First, not all of the “legitimate” authorities are “good guys” (all the time :). Second, I’m not aware of any “network security” tool that hasn’t been subverted at some point in time.
Again, to clarify, this mechanism for use on intranets within a single span of administrative control. Like you, I would work to dissuade anyone from using it across the public Internet.
The likely result of the “static-dh-…” proposal is improved mass surveillance by authorities, and exploits of this mechanism by the organized crime.
Let's remember that this technique is in use on intranets around the world, and that's the focus, here.
To those who need that surveillance: stay with TLS-1.2.
Unfortunately, this isn't possible due to regulatory oversight and plain old bit-rot.
Either you have PFS and the bad guys will benefit from it too (so you need to detect and fight them using other methods), or only the bad guys have PFS and you might [0] detect them because their “protection quality” stands out amidst the ocean of the automatically-inspected & censored traffic.
The ability to infer superencryption is quite important, per the above.
Because there are well-known ways of hiding the presence of encryption, at the cost of increase of the ciphertext size.
We should also keep in mind that are also ways to counter-detect these obfuscation techniques, too.
The hope that the encrypted traffic would stand out is unfounded.
Actually, it does stand out, in many cases.
Considering how fast the attack sophistication is evolving, the likelihood that “they” would employ other countermeasures, but ignore this one is fairly low.
This technique certainly isn't a universal panacea, as you rightly point out. But it's an extremely valuable and important technique that's been in broad use for quite some time, so maintaining a mechanism for intranet operators to analyze TLS-encrypted traffic within their own spans of administrative control is important and worthwhile, IMHO.
We don't want to inadvertently drive them into using proprietary, non-auditable crypto. That would be bad for everyone.
----------------------------------- Roland Dobbins <rdobb...@arbor.net> _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
