[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: private algorithms and the DS record

Scott Rose wrote: 
-----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.

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.

True, this problem won't present itself in the (normal) case of not understanding any private algorithm identifiers.

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.


Yes, exactly.


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)?

Er, no, it doesn't have to be done if you know you can't do anything with the DNSKEYs. That is how I understand the logic, anyway.

In any case, the reaon why adding the name to the DS is more attractive is the symmetry with DNSKEY and RRSIG. It looks to me that the fact that this was NOT done was just an oversight. A not surprising one, considering.

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