Ultimately, I can’t at all complain about armchair engineering. The whole point of Source Port Randomization as an interim fix was to get things to the level that we could all have the big messy discussion about what to do now, without being illuminated by the actively burning state of the DNS infrastructure.
Now. When it comes to fixing DNS, we have to operate under the same constraint as when we suggest fixes to web browsers. Just as you’re not allowed to break the web, you’re not allowed to break DNS. There are indeed many things we could do to make the web a safer place, “if only a bunch of people would re-code their web sites”. That is, unfortunately, a naive approach that doesn’t actually lead to things getting any safer. If nobody will deploy the fix, it’s just as if the fix didn’t happen.
We needed this DNS fix to happen.
As I’ve said a couple of times, Dan Bernstein was right. Source Port Randomization (SPR) is not perfect — I’m pretty embarrassed that we didn’t recognize how common interactions would be with firewalls — but it’s a remarkably flexible and thorough improvement to the status quo. When I said in my talk that there’s fifteen ways around the TTL, I wasn’t kidding. From magic query types that are uncached by a recursive server, to nonexistent query types that are ignored by an authoritative server, there may not be a TTL to override. Or perhaps the attacker actually provides records for 1.google.com, 2.google.com, 3.google.com, and so on. In other words, the attacker might not even try to overwrite the NS for a domain — he may just want to get a domain in. How would this be useful? Consider the web security model, and Mike Perry’s research on cookies. 1.google.com will collect the cookie for Google just fine.
Or perhaps, as in the case of Google Analytics and Facebook and most large, CDN hosted sites, the actual TTL to override needs to be small, for reliability and scaling purposes.
In all of these situations, Source Port Randomization — a solution forged in 1999, long before we recognized all these problematic variant attacks — poses a significant barrier to attack. It’s not a panacea, but it was never said to be one. The hope, and it’s not unreasonable, is that it’s a lot easier for secondary defenses to detect and correct for a flood of billions of packets, than a couple of thousand. SPR’s purpose was to provide a safer environment for an active discussion that would hopefully yield better fixes. And that’s what it’s doing!
So, lets finally start talking about the better fixes that are emerging. Specifically, the problem is — how do we stop the blind attacker who’s willing to send us four billion packets in order to pollute a name? Four major strategies are, at least from what I’ve seen, making real strides towards a better fix.
No comments:
Post a Comment