Subject: Re: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft (fwd)

From: [email-masked] (Ted Lindgreen)
Date: Wed, 31 May 2000 12:16:07 +0200

[Quoting Edward Lewis <[email-masked]> ]
>
> >If the draft would have proposed that the meaning of a KEY bit set
> >in the NXT RR   AND   no KEY RR is present, were :
> >   "a NULL-KEY is implied"
> >we would not have this problem. This would then also be downward
> >compatible.
> 
> I think this is where I am heading with the draft.
> 
> The bit would be on if the parent signs a key set for the child that
> includes a zone key, hence "securing" the child.

No, this would mean something quite different, but both
proposals have problems.

Actually we have 4 different questions:

1. How bad do we need to get rid of the NULL-KEY?

2. Is the KEY-bit in the NXT-RR redundant information, i.e. can
   we use the case "KEY-bit set _AND_ no KEY RR present" to get
   rid of the NULL-KEY?

3. Do we need to retain the exact functionality of the NULL-KEY?

4. Do we need to add new functionality, i.e. "the parent has signed
   this childs KEY"?

Let's review them one by one:

ad. 1.
   For large TLDs it would be nice to get rid of the NULL-KEYs as
   it reduces the size of the zone file with some 30%.
   However, this reduction is dwarfed by the growth of 20% every
   month which these TDLs are currently facing.

ad. 2.
   The original meaning of the KEY-bit in the NXT-RR is that an
   RR of type KEY is present. Now what happens if we set this bit
   and omit the corresponding RR?
   - If we define this case to imply a NULL-KEY, it opens a
     security leak:
      spoofers "caching" server needs only to present the original
      NXT and faked NS-glue-RR's to certifyably fool a secure
      aware resolver.
   - If we define this case to imply "the parent signs a key set
     for the child that includes a zone key":
     - In the backwards-compatible mode it would mean the parent
       zone is BAD.
     - If the child holds the KEY and SIG, the KEY-bit info is
       redundant, as it must have been there anyway to conform
       to RFC 2535.
     - If the child does not hold a KEY the child zone is BAD.
   Now, suppose the KEY-bit is off (and of course no KEY-RR either):
   - In the original RFC-2535 this would mean that the child MUST
     have its own KEY (and is otherwise BAD or hi-jacked).
   - As proposed in the Draft, it would mean that the child is
     certifyably unsecured. This opens a security leak for
     externally signed childs.
   In conclusion we think it is very dangerous to allow the KEY-bit
   to indicate something else than what RFC-2535 intended it to mean.

ad. 3.
   The functionality of NULL-KEY is to indicate the end of a
   secured branch of the DNS tree. This functionality is
   needed to prevent zone-jacking. If we want to get rid of
   the NULL-KEY (and more important its SIG), we need something
   that _exactly_ reflects its functionality.

ad. 4.
   The proposal in the Draft replaces the functionality of the
   NULL-KEY (end of security) by "parent has signed". We think
   the latter info is redundant, as:
   1. There MUST be a zone KEY when no NULL-KEY  is present.
   2. There MUST a SIG over the KEY to validate it.
   3. This SIG provides the necessary info about its signer
      already and in a certifyable manner.

So, in conclusion, we think that:
- The need to get rid of the NULL-KEY is a minor issue.
- Misusing the KEY-bit in the NXT-RR is both dangerous and
  unnecessary.
- The functionality of NULL-KEY is needed.
- The proposed new functionality is not needed.

> The problem with allowing both the NULL KEY to signify an unsigned child
> *and* a bit setting in the NXT is that this complicates life for the
> resolver (and I don't mean that only the code is hard to write).

The functionality of the KEY (or NULL-KEY) is to indicate that the
zone, to which the KEY belongs, is secure (or unsecure).

The functionality of the bits in the NXT is to indicate what RRs
are present in the RR-set.

These functionalities are different, and both are needed for
security. That security complicates life for the resolver is true
and unfortunate, but using shortcuts that open leaks is worse.

Regards,
-- Ted.

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