[dns-operations] Unplanned DLV zone outage on 2009-Apr-06

[Michael Sinatra]

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* 
out-of-band verification.

>> 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.

michael