Re: private algorithms and the DS record

[David Blacka <davidb@verisignlabs.com>]

Scott Rose wrote:
> Well, the validator needs to obtain the DNSKEY RR anyway to validate the DS
> RR (the hash uses the entire RDATA of the DNSKEY).  If there are two private
> algorithms in use, then the validator must rely on the key_id to
> differentiate.
>
> I wouldn't expect a validator to make any decision on a zone based solely on
> the DS RR since it can only validate the RRSIG and not the key hash without
> the DNSKEY from the child zone.

Huh?  I don't even know what this means.  Validators validate RRsets, 
not individual fields in a record.

In any case, if what you are saying is correct, then the text in 
protocol-09 is (very) misleading, perhaps even wrong.

What I am saying is that protocol-09 states that the validator makes a 
decision based on the (verified) DS set from the parent, and that this 
causes a problem wrt private algorithms.  Have I utterly misinterpreted 
this paragraph?

   If the validator does not support any of the algorithms listed in an
   authenticated DS RRset, then the resolver has no supported
   authentication path leading from the parent to the child.  The
   resolver should treat this case as it would the case of an
   authenticated NSEC RRset proving that no DS RRset exists, as
   described above.

or this paragraph (both from section 5.2 of protocol-09)?

   If the resolver does not support any of the algorithms listed in
   an authenticated DS RRset, then the resolver will not be able to
   verify the authentication path to the child zone.  In this case,
   the resolver SHOULD treat the child zone as if it were unsigned.

Note that this problem is very easy to fix.  Either make it clear that 
this logic only occurs after matching the DS to the DNSKEY, or (and this 
 is even easier) define how the private algorithm identifier is put in 
the DS record.  Like, prepend it to the key hash, which is essentially 
like how it is done for DNSKEY and RRSIG now.

--
David Blacka    <davidb@verisignlabs.com>
Sr. Engineer    VeriSign Applied Research

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>