[dns-operations] Unplanned DLV zone outage on 2009-Apr-06
michael at rancid.berkeley.edu
Wed Apr 15 04:51:24 UTC 2009
On 04/14/09 17:33, Eric Osterweil wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> First: this whole discussion is all ignoring the implications of using a
> 3rd party for inline validation (privacy, etc.) vs. constructing local
> TA lists. For the rest of this discussion please recall that I think
> resolvers should cull their own TA lists and manage them locally, but
> inline mechanisms exists and some prefer to use them, so we have the
> following discussion.
Are you arguing that all "inline" (i.e. DLV?) mechanisms are the same
from a perspective of trust?
> Given that edu cannot delegate to you (as com cannot delegate to
> foo.com), how do you plan to declare your intent to be secure? There
> isn't (at present) any way to declare this to everyone (modulo an
> unsigned parent). I know there are some who like to subscribe to the
> idea that there is one TA registry in the sky that we all should trust,
> but not everyone _has_ to believe this or use them. That doesn't make
> anyone bad in any way, but you have to realize that not everyone has to
> play by one group's rules. By contrast, is there any reason that you
> should necessarily _not_ be able to be trusted by someone who simply
> wants to use a different TA registry? Are you now going to run to all
> of the would-be registries (assuming you could even know who they all
> are) and get your keys in them and maintain their correctness, or are
> resolvers just out of luck if they don't agree with/know to use your TA
> registry of choice? This seems a little difficult to imagine at any
> scale, no?
> None the less, people who want to benefit from deploying DNSSEC below an
> unsigned parent should not have to get one group's blessing, etc.
I am not talking about one group's rules (although ultimately, we _will_
need to play by our parents' rules). I am talking about out-of-band
verification of trust (by *some* rules, and rules that are documented)
versus in-band scraping of keys (i.e. zero trust, zero rules).
>> Consider another example: Someone spoofs a zone in such a way that all
>> of your pollers get the same key information and SecSpider regards
>> that information as valid.
> Before we jump here... How? This is within the realm of possibility,
> but can you tell me how likely you consider this? I also consider it
> possible for a TA registry to have one of its servers get pwnd and then
> we could have an adversary affect all of the clients of that server too,
> no? Seriously, what degree of realness are you supposing here? I
> mentioned in my first email the lengths we go to.
Again, this is the out-of-band versus in-band distinction. Out-of-band
is feasible and the trust gains are significant.
>> Now there is a trusted fake zone with bogus information that users of
>> SecSpider regard as "secure." Unlikely scenario, but it seems that it
>> is a much better idea to have key management done out-of-band from the
>> DNS protocol itself.
> If I pop a TA operator's box and insert a key we have the same
> situation, right? Also unlikely, but possible, yes?
You'd have to compromise the box, insert the key, *and* spoof the zone.
In your model I only have to spoof the zone.
A better model would be one that provides continual polling *and*
>> I can see where SecSpider would have use in testing and research, but
>> I assume you're not advocating it for production use.
> Right now, there are thousands of zones (that we know of) that have
> deployed DNSSEC and who are not able to benefit from it because their
> keys are not part of a single group's verification process. The idea
> that I put data in public and then expect it to be ignored may seem fair
> from one perspective but maybe not the best practice because of others'
> perspectives (resolvers use what you put in your public zone). There is
> no protocol semantic for the root of an island to signal to resolvers
> that it wants (or doesn't want) its keys to be used.
And I am suggesting that by assuming that the a zone owner always wants
the keys to be used, you are making that problem worse, not better.
> The biggest problem I see here is that trust really isn't black and
> white. Given you _know_ something about a key (like it's _your own_
> key), you may trust it. For another key, given no other information
> aside from its global consistency, you may feel safe using it. If you
> see a key in a DLV do you "trust" that as much as your own KSK? What if
> they disagree? No matter what, trust is not a boolean. SecSpider
> provides you information about keys that you likely would not have heard
> of otherwise *period*. In the absence of _any_ other information, this
> is meant to help resolvers make informed decisions. Yes, I think this
> can be very helpful in production and I think it highlights some needs
> of the protocol.
The fact that we cannot create a perfectly antiseptic environment does
not mean that we perform surgery in a sewer. I know that I cannot have
perfect trust, so I decide what level of trust (>0) I am willing to
accept based on my evaluation of the various risks (including my own
ability to do out-of-band verification and key management). I could
decide to trust ISC, or IANA, or some other TAR, or some other DLV.
Look, I like SecSpider, and I think it performs an important service. I
have used it as another (but not the only) check to make sure I have
correct keys in my trust repository. But I do not believe that
SecSpider should be proffered as an alternative to trust-anchor
repositories and DLVs that do out-of-band verification of keys, and I am
very concerned that that's what you're doing.
More information about the dns-operations