Re: null DK records at the parent

[Roy Arends <Roy.Arends@nominum.com>]

On Wed, 6 Jun 2001, Ted Lindgreen wrote:

> [Quoting Roy Arends, on Jun  6,  2:20, in "Re: null DK records  ..."]
> 
> > When a dnssec-aware-resolver stumbles upon a child which claims to be
> > secure, I see 3 different options.
> 
> I think this sentense reviels two general misunderstandings:
> 
> 1. A resolver does not "stumble" onto childs.
> 2. A child can not claim to be secure.
> 
> ad 1.
>  DNS is designed for, and used to, lookup specific information. It is
>  not a search mechanisme.
> 
> ad 2.
>  If anyone uses claims from a certain zone itself, this zone
>  is by definition hijackable.

Let me ellaborate a little on my comments:

I meant to say, if the parent holds no information on the childs security
status (with sig@parent/DK in mind, not with RFC 2535 in mind on this
issue) and a secure aware resolver gets a query-response which holds
dnssec RR records (DK,SIG,KEY or NXT/NO) "it stumbles" on this info,
because it did not expect this info. You might want to check that I
mentioned in the line before the one you quoted:

 "If the parent does not consider the child to be secure... "

In this case, "a child claims to be secure" means, it has all the
information it can to be secure, and is therefore dependend on the parents
information on the childs secure status. If the parent does not specify
this info, the child "claims" to be secure. This is not the same as "the
child is secure". 

** Its all in the eye of the resolver **

My apologies if this had somewhat confused the reader. 
 
> To be secure aware, a resolver must establish the security of a
> particular zone independendly of that zone.
> And then, if the zone is indeed supposed to be secured, it must
> check the chain from a known (i.e. preconfigured) KEY towards the
> SIG of the RRset that it had asked for.
> The chain can be followed forwards or backwards, but that is an
> implementation issue (I guess that a wisely written implementation
> caches KEYs after verification, so it does not have to go down and
> up all the time for every lookup).
> 
> So, how does that impact on your statements:
> 
> > 1) the child key is self-signed and the resolver has this key
> >    preconfigured:
> >    It can easily verify the signatures. (but then, why would this resolver
> >    go top down from the root)
> 
> This is correct, we are talking about a secured entrypoint here,
> with the info directly available.
> 
> > 2) the child key is self-signed and the resolver has no knowledge of this
> >    key: unsecure zone. 
> 
> This statement is incorrect.
> There are 2 possibilities:
> A. The resolver has established that this child is secured, but the
>    key used is unknown, then it follows that the child is BAD and
>    certainly not unsecured.
>
> B. The resolver has established that this child is not secured,
>    then childs KEY RRs (if any) are irrelevant.

See my statements above. Only B is relevant here, and therefore identical
to my statement. 

> > 3) The child key is signed by some key other then their own or its parent:
> >    The resolver needs to securely resolve this key (or could have it
> >    preconfigured).
> 
> Again incorrect, see f.i. B above.

See my statements above, and Olafurs statement on this pointing at
RFC3090.

Regards,

Roy Arends
Nominum