Re: private algorithms and the DS record

[Rob Austein <sra@isc.org>]

At Tue, 21 Dec 2004 16:18:57 -0500, David Blacka wrote:
> 
> Samuel Weiler wrote:
> > 
> > I concur with Rob: this adds unnecessary ugliness to the DS RR, and is
> > likely a backwards-incompatible change.  I don't want to have to dust
> > off 3755 and wait for IANA again.
> 
> Backwards-incompatible with what?

At least one of us is confused.

If I understood you correctly, you proposed that the DS RR "Digest
Field" (-records-11 5.1.4), which currently holds a digest calculated
on the same field of the corresponding DNSKEY RR regardless of the
signature algorithm, should be changed to include a second copy of the
private algorithm identifier as a special case for the private key
subtypes of the DNSKEY RR.  This would be an incompatable change to
the content of the DS RR: currently deployed code based on the current
specs would have to be changed, since otherwise digests would never
match for the private key subtypes.

Please note that, if you follow the definitions in -records 5.1.4,
2.1.1 through 2.1.4, and A.1.1, the private algorithm subtypes (253
and 254) -already- include the private algorithm identifier (DNS name
for subtype 253, OID for subtype 254) in the public key field (2.1.4),
which is of course already included in the hash (5.1.4).  You appear
to be proposing that we include a -second- copy of this private
algorithm identifier in the DS hash, for reasons that escape me.

Or perhaps you're proposing to include the raw private identifier
algorithm itself rather than its hash, and the hash field of the DS RR
is now to contain the concatenation of the private algorithm
identifier and the hash, again special-cased just for the private
algorithm subtypes, which is again not backwards compatible.  If this
is what you meant, the case for it is a bit more understandable, but
it's still unnecessary, since that identifier is already an input to
the hash and is thus already available for you to use without
requiring a non-backwards compatible change.

Yes, there is deployed code, at least three implementations if I
recall correctly (nsd, bind9, Net::DNS::SEC, perhaps others I've
forgotten).  Yes, we could change all of them if we had to, but I
don't think you've yet demonstrated any real need to do so.

At least one of us is confused.  Perhaps it's me.

> > Concur with Scott and Rob: there was no particular consideration given
> > to private algorithms.  If there had been, I still doubt we would have
> > changed anything.
> 
> The text of protocol-09 section 5.2 does not support this postion.

Hmm?  -protocol 5.2 talks about what happens if one doesn't support
any of the algorithms listed in the DS RRset.  In the case of private
algorithms, yeah, one has to retrieve the child's zone's apex DNSKEY
RRset and compute the DS hashes in order to figure out precisely which
algorithms are listed in the DS RRset.  So what?  Please show me where
it states that the validator is not allowed to retrieve the DNSKEY
RRset if it needs that RRset in order to figure out whether it
supports the algorithms listed in the DS RRset.  It has to retrieve
that same DNSKEY RRset anyway if it does understand any of the
algorithms, so what's the issue here?

As stated in an earlier message, I think you've found a place where an
obvious optimization doesn't work for private algorithms, so one has
to do it the slow way.  Subtyping sure is a pain, isn't it?

--Rob

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