On 2013-06-11 22:40 , Sebastian Castro wrote:
You just touched a very sensitive nerve. One of the missing parts of the DNSSEC ecosystem is how to guarantee the validating resolver is playing nice. Because the current protocol only provides a one-bit flag to signal if the data was authentic or not, a non-cooperative resolver can simply lie and tell you... "yeah, this data is valid, see the flag?"
If you don't have external reasons to fully trust the validating resolver (ie, it might lie to you, or the responses might be altered in between the validating resolver and the application), _and_ you don't check the trust chain from known good root information, then yes, something in the path could lie to you. There isn't any obvious solution to that which doesn't involve checking a chain of trust in-application. The validating resolver providing more than a one bit flag stating it has checked it, and it's "all good guv", doesn't help: it can still lie, no matter how you dress that up. Without an external reference, you have the self-signed-certificate problem: in order to trust it, you have to trust it.[0] Basically if your "validating resolver" is outside the host you are running on, you're at most crossing your fingers and hoping for the best if you delegate verifying DNSSEC to something else. If the resolver you're trusting is "outside your AS" (eg, upstream provider), you'll need a bunch more fingers to cross (there's a lot of untrusted network in between).[1] Either you really care that the DNSSEC is valid, in which case you validate it yourself (in application), from the root. And do something meaningful in the case of (apparent) subterfuge. Or you accept that what you have is at best "a (tiny) bit better than what you had before" and life goes on. External validating resolvers are, at best, a stepping stone on the path towards full DNSSEC deployment. A necessary step in practice, I think. But they can lie to you too. All you've done is moved your "point of total faith" a bit closer to you. Ewen PS: In a fully checking DNSSEC world these DNS tricks (forged data) may well end up being equivalent to "not answering". Which is also an option today. It's just likely to cause more helpdesk calls stating "the Internet is broken". So much as I too dislike forged data, if the choice is "no answer, it's broken" and "forged data, point at a message saying it's broken" I'd probably lean towards forged data too. [0] Having, eg, a SSL key for the validating resolver doesn't stop it lying -- it just helps you avoid listening to others lie to you: you gain some certainty on where the lies are coming from.... which helps with attribution, but not with certainty you're not being lied to. [1] Maybe you're even crossing your fingers if the validating resolver is on the same host; but if the intruder is in your host, affecting what the validating resolver says, you probably have bigger problems.