Re: null DK records at the parent

[ted@tednet.nl (Ted Lindgreen)]

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

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.

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

> In any case, important is when a child is bad: 
>    only if the parent states that a child is secure, and the child can
>    not offer valid signatures. Defining valid in this case: No sigs or
>    corrupt sigs.

Yes, indeed this is the important question, however, the answer
given is incompleet, I'm affraid:
- If the parent states that a child is secured, then not only must
  the child have valid sigs, but also the KEY that the child has
  used must be checked. Usually (on-tree validation) by checking
  the parental SIG over that KEY.

The real questions are:
1. How does a (secured) parent state that a child is secure, and
   how if it is not secured? Important is, that this is done in
   a manner that can be implemented and maintained in real-life
   situations (think of large TLDs).
2. How does a resolver find this out in a predictible manner from
   possible second- and third-hand cached information?

I don't have all the answers, but for now, I have concluded:
- Following RFC2535, with NULL-KEYs @ parent and real KEYs @ child
  makes 1 very difficult.
- Using the SIG@parent idea solves the problems in 1, but
  introduces problems in 2.
- The idea of the DELS RR seems to solve the problems in 1,
  without introducing problems in 2.

Regards,
-- ted.