On 7/17/2017, 11:04, "Roland Dobbins" <rdobb...@arbor.net> wrote:
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.
Something similar was brought up several decades ago, when some agencies
expressed concerns that wide-spread availability of encryption would make
national security and law enforcement jobs impossible. Thankfully, those fears
proved unfounded then. They are likely to prove so now.
> 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.
“Intranet” is an administrative term, and has no technical meaning. As such, it
has no bearing on the protocols.
Not to mention the obvious lack of enforcement mechanisms – how are you going
to enforce on the protocol level that “this technique” never crosses the
administrative domain?
> 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.
You can’t seriously expect this method of surveillance to stay available
forever, as the criminals get smarter and their tool chest gets enriched by
exploits from higher-level organizations?
In any case, there are better mechanisms and tools to address this risk.
And it's used to detect and prevent malware downloads by intranet user
populations.
There are better tools for that.
> 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.
You must be lucky then. Criminals that we’re concerned with, aren’t that dumb.
> 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.
My point is that we should look at the trend – not just the status quo. And the
trend shows the attackers become smarter.
> 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.
If the adversary allows you to infer it. It’s next to impossible with the
large-scale traffic, when the adversary is crafty enough.
> 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.
Again, technically there is no such thing as “intranet”. It’s an
*administrative* domain, and there is no distinction protocol-wise.
The only “dissuade” I’d consider is when it’s enforced on the protocol level
(on the wire), and there are unambiguous ways to detect it (and explicitly opt
in, or opt out).
> 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.
Let’s not forget that from the protocols point of view there is no “intranet”.
There’s only “Internet” – a network of interconnected networks. Administrators
can draw boundaries around hosts and routers they think they control – but it
has no impact on the protocols themselves.
> 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.
First, this ability depends on your adversary letting you have it – it is not
given. Second, I find it concerning that you seem to be OK with the second
option of the choice I outlined.
> 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.
For an individual connection – very likely so. For all the connections your
subjects have within the company, and/or with the outside world? Not hardly.
> The hope that the encrypted traffic would stand out is unfounded.
Actually, it does stand out, in many cases.
In fewer and fewer cases. As adversaries learn, they encode that learning into
the tools that then become available to the lower-skills-level attackers.
> 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 disagree here.
Not to mention that a country might consider the entire traffic within its
borders as “intranet”. Some already do (and some don’t even stop there). I’d
rather that these operators mature and realize that as the time goes, some new
capabilities arrive, and some old capabilities wither and die.
We don't want to inadvertently drive them into using proprietary,
non-auditable crypto. That would be bad for everyone.
Publish that crypto, and it’s not proprietary any more. Subject it to an audit
– and it’s now audited/auditable.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
