RE: private algorithms and the DS record

["Scott Rose" <scottr@nist.gov>]

> -----Original Message-----
> From: David Blacka [mailto:davidb@verisignlabs.com]
> >
> > 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.
>

Maybe I misunderstood your post, but your reply clears it up.


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

A validator would not know if it supports the private algorithms until it
got the DNSKEY RRset from the parent and finds out which private algorithm
is used.  Was that the idea?  This seems to be a corner case:  If a resolver
doesn't understand any private algorithm and encounters one in a DS, it
behaves according to the paragraph above.

In the case where the resolver understands one or more private algorithms,
it cannot make a statement of the security of a child without getting the
child DNSKEY RRset first.  I think that's the crux of the issue.

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

The former situation (matching DS and DNSKEY) has to be done anyway, what
makes that less attractive than adding the name of the algorithm to the DS
hash (besides the work in obtaining and processing the DNSKEY RRset)?

Scott


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