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

[Eric Osterweil]

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


On Apr 14, 2009, at 5:50 PM, Michael Sinatra wrote:

> On 4/14/09 3:44 PM, Eric Osterweil wrote:
>
>> We only serve keys that were seen during the last poll and that  
>> have valid RRSIGs (i.e. if they've expired we don't list them).  If  
>> a zone signs for (say) a month, and then removes its signed  
>> material the next day, that's already a bit of a faux pas.   
>> Something like that can cause a lot of problems for that zone if  
>> data is cached somewhere, or if someone wants to replay data into a  
>> cache w/ the still valid RRSIGs anyway.  We will stop listing the  
>> keys, however, if they are not present the next time we crawl.
>
> There's a big difference between signing and placing a trust anchor  
> somewhere where you *know* people will use it and then unsigning  
> your zone and leaving the trust anchor in place, versus placing a  
> signed zone into production with no trust anchors anywhere (==an  
> insecure zone).  In the first case, you have created a broken zone,  
> and you should know that you have done so.
>
> In the second case, you have created an insecure zone which you have  
> not explicitly asked anyone to trust.  But then someone comes along  
> and scrapes your zone without your knowledge and puts the keys in a  
> repository that others trust.  Now you're in a situation where  
> people are trusting your DNSSEC without your knowledge.  If I assume  
> nobody is trusting my zone, is it really that big a faux pas to un- 
> sign it or change the signing keys?  Or is it a bigger faux pas to  
> create a mechanism where people trust my zone without my knowledge?   
> (I hope that  this is not the way SecSpider works.)

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.

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

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

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

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.

Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (Darwin)

iEYEARECAAYFAknlK14ACgkQK/tq6CJjZQL4TwCgh0YcNKY6ll9psBDgLasixVnh
lDMAn2Ws8Wkuxc0fTAZ2RJXS8NtbrVEP
=baCB
-----END PGP SIGNATURE-----