Subject: Re: null DK records at the parent

From: [email-masked] (Ted Lindgreen)
Date: Wed, 6 Jun 2001 11:02:53 +0200

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

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Roy Arends <[email-masked]>
Date: Wed, 6 Jun 2001 14:14:39 +0200 (CEST)

>   the parental SIG over that KEY.

Yes, I fixed this in my second posting.

>   without introducing problems in 2.

This doesn't state anything new or clearifies your opinion on null-DK
records at the parent.  I assume DELS RRs and DK RRs are similar ? 

Regards,

Roy Arends
Nominum

---

From: Roy Arends <[email-masked]>
Date: Wed, 6 Jun 2001 15:53:31 +0200 (CEST)

>  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. 
 
>    then childs KEY RRs (if any) are irrelevant.

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

> Again incorrect, see f.i. B above.

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

Regards,

Roy Arends
Nominum