On 11/06/13 23:26, Ewen McNeill wrote:
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?"
Thank Ewen for this, you are covering three interesting problems: 1) How do you establish and keep trust on your resolver 2) How do you know if your resolver is not lying to you 3) How to protect from traffic between you and your resolver is not being tampered.
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]
This is an example of issue 3 noted above. For this, for example, OpenDNS proposed a solution called DNSCrypt (http://www.opendns.com/technology/dnscrypt/) Running a validating resolver locally has been the trend lately, but it's a practice that's limited to hosts with some computing power, for example, doesn't sound like a good idea on a smartphone because it will increase the power consumption. On the matter of locally-running resolver, NLnetLabs (the same authors of unbound) have this project called dnssec-trigger to have validation on your host: http://www.nlnetlabs.nl/projects/dnssec-trigger/
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.
Effectively we are making little gains at every step, but still we are not totally there with solutions for all the issues. There a lot of work to do :)
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. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535