Subject: private algorithms and the DS record

From: David Blacka <[email-masked]>
Date: Thu, 16 Dec 2004 15:17:14 -0500

I was thinking about the use of private algorithms in DNSSEC the other 
day, and it struck me that they might not, strictly speaking, work.

Note that records-11 has the following text in Appendex A.1.1:

    Algorithm number 253 is reserved for private use and will never be
    assigned to a specific algorithm.  The public key area in the DNSKEY
    RR and the signature area in the RRSIG RR begin with a wire encoded
    domain name, which MUST NOT be compressed.  The domain name indicates
    the private algorithm to use and the remainder of the public key area
    is determined by that algorithm.  Entities should only use domain
    names they control to designate their private algorithms.

Fair enough, but there are no instructions for the DS record.  So how 
would a resolver be able to distinguish between a known private 
algorithm from an unknown private algorithm from the delegation?

Note this text from protocol-09, section 5.2:

    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.

I.e., it is expected that a DNSSEC validator would be able to make the 
determination that it does or does not support any of the algorithms 
directly from the DS set.  As soon as a DNSSEC validator knows about one 
private algorithm (per scheme), it suddenly cannot make this determination.

Or am I missing something?

-- 
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

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

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 20 Dec 2004 12:52:16 -0500

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.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David Blacka
>
> On Dec 17, 2004, at 10:54 AM, Olaf M. Kolkman wrote:
>
> > Are you refering to algorithm id clashes?
>
> yes.
>
> Private algorithms are identified with an algorithm number (253 or 254)
> and an additional DNS name or OID.  When you are looking at a DNSKEY or
> RRSIG, you can figure out exactly what the algorithm name is by looking
> at the number, seeing that it is 253, then looking at the beginning for
> the key data or signature data and parsing a DNS name.
>
> Nobody has implemented this that I know of, but it looks easy enough.
>
> HOWEVER, when the resolver is following a delegation, it 1) looks for
> the presence or absence of the DS set.  If present, it makes sure that
> it understands at least one of the algorithms presented in the DS
> record.  BUT, it cannot tell if "253" refers to a private algorithm it
> has heard of or some other private algorithm, because there are NO
> INSTRUCTIONS for putting the private key DNS name or OID in the DS
> record anywhere.  Therefore, one has to assume that it is not present.
> Thus, the only information that the resolver has at that point in the
> validation process is that the DS record is using *some* private
> algorithm, but it cannot tell which one.
>
> Basically, all I am pointing out is that private algorithm identifiers
> need to be handled everywhere algorithm numbers appear.  And the DS
> record is missing information about to handle private algorithms.
>
> It is true that, if the validator goes on to the subzone and fetches
> the DNSKEYs, it can match the DS to the DNSKEY and actually find out.
> BUT, the way protocol-09 is written, that isn't how validators are
> expected to work.
>
> --
> Sr. Engineer    Verisign Applied Research
>
>
> --

---

From: David Blacka <[email-masked]>
Date: Mon, 20 Dec 2004 13:21:59 -0500

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

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.

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 20 Dec 2004 13:53:50 -0500

> From: David Blacka [mailto:[email-masked]]
> >

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

>     authenticated NSEC RRset proving that no DS RRset exists, as

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.

> 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

---

From: David Blacka <[email-masked]>
Date: Mon, 20 Dec 2004 14:09:49 -0500

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

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

> child DNSKEY RRset first.  I think that's the crux of the issue.

Yes, exactly.

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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 31 Dec 2004 16:45:21 +0000

> I see #5
> 5) Remove special handling of Private Key's in RRSIG, i.e. do the same
> thing as in DS and cementing Private algorithm's second class status.

i agree.

> Personally I think 2 is the most appropriate approach if this is
> big enough a issue to warrant the attention of the working group.

though i prefer #5, i agree that #2 is the right fallback choice.