|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: DNS Hijacking by Cox
Several people have email me privately to disagree with my statement about DNSSEC, on various grounds. I stand by my statement, but I am making a fair number of assumptions, some perhaps invalid. Let me be less terse. I'm assuming fairly universal deployment. In other words, the root zone is signed, as is most or all of .com/.net/.org are signed and the .ccTLDs of your choice. I don't assume that domains under, say, .com are signed, but of course unsigned zones aren't protected. I assume that user machines have a configuration file with the root keys. (I'm carefully not saying anything here about how root key rollover is done.) I'm assuming that ISPs are *not* changing that configuration file; this may be a dubious assumption. One correspondent felt that it was; I stand by my statement, because if the ISP plays games there and the user falls to a pharming attack that DNSSEC may have prevented, the ISP may be liable. Besides, there's an easier attack for the ISP... DNSSEC can be end-to-end, or it can be terminated by a full-service caching server which has a security association with user resolver (typically via TSIG, which uses shared secrets). In that case, the caching server would verify the digital signatures and set a bit in the response to the user saying "all is cool". This is the most likely way an ISP would spoof a response, since it doesn't strip protection from other zones, doesn't require them to do massive resigning, etc. The way this is signaled by the end-user's resolver and handled by the caching name server is complex (see Section 3.2 of RFC 4035); briefly, though, it's ultimately under the control of the end system. I have no idea what the Windows default will be or if it will let the user's machine do its own validation. My guess, though, is that it will prefer ISP validation but be able to do it itself. Note that 4035 requires a secure channel (i.e., a shared secret) for upstream validation; since that won't exist out of the box, the PC would have to be able to do its own. For obvious reasons, I'm focusing on Windows here. It's 99% certain that Linux and *BSD machines can do their own checking, if they wish; I'll leave to others to speculate what MacOS will do. The net, though, under my assumptions, is that ISP-supplied user configurations will likely have the user's machine trust them, but sophisticated users will be able to override that -- and DNSSEC is very much something for sophisticated users. The ISP can always ignore the RFC and strip out the signature RRs. That's detectable by an end-system that has requested that they be sent along. After all, that's no different than a monkey-in-the-middle attacker doing the same thing -- DNSSEC doesn't distinguish between offensive ISP and other enemies... So -- I think that DNSSEC, if deployed, will protect users who care, even against their ISP. It won't protect the clueless; I'm not sure what will. (See http://didierstevens.wordpress.com/2007/05/07/is-your-pc-virus-free-get-it-infected-here/ for an example of people you can't protect with technology...) But it is, as the tube of toothpaste almost says, an effective attack-prevention mechanism if used as part of a program of good Internet hygiene and regular professional care.
|