[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: private algorithms and the DS record
Rob Austein wrote:
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.
I think that now we are getting somewhere.
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.
Why would a validator ever match a DS with an unknown algorithm to a DNSKEY?
My central assumption here is that while there is deployed DNSSEC code,
there is no deployed DNSSEC code that thinks it understands any private
algorithm.
So, with the currently deployed base, what difference does it make that
a DS with a private algorithm would never match a DNSKEY? It could
never be used anyway.
If, in the future, implementations add private algorithm support, why
wouldn't they be able to understand this extension?
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.
Re-read section 5.2, and tell me how to reconcile the advice given there
with how private algorithms are defined. You might want to re-read my
first few posts on this subject.
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?
To elaborate on my statement: I disagree that we would not have changed
*anything*. At the very least, this corner case would have been
mentioned somewhere in the document (either section 5.2 or A.1.1, I expect).
My issue is not that the behavior you suggest is disallowed, but that it
also isn't mentioned anywhere. How is a future implementer supposed to
know what the issue is here?
Keep in mind that the case under discussion is about when the only
difference between the DS set containing zero supported algorithms and
one is a private algorithm. If the DS record contains one DS with a
private algorithm and one DS with algorithm 5, the whole issue will
never come up.
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?
It is certainly more of a pain when the subtyping is applied inconsistently.
I am in no way wedded to the idea of modifying the format of the DS RR.
It just looks like the easiest way to solve the problem that I am
concerned about.
My central issue here is that I am concerned that, if someone were to
implement private algorithms, they would not, in the final analysis, work.
My original point was the conflict between how private algorithms are
defined to work in Appendix A.1.1 and the text in section 5.2. I could
requote it all here, but I think I will just point you all back to my
original message starting this thread. The gist of it is that section
5.2 implies that a validator makes the decision about whether or not to
treat the child zone as signed or not from the DS set alone.
That this technique is, in fact, an optimization of a slower algorithm
may, in fact, be true, but this slower algorithm is *not* *documented*.
Maybe I'm just too pessimistic here. When I see something that is
unclear and confusing to me, I assume that it will also be unclear and
confusing to others. Maybe it won't.
I see four possible resolutions here:
1) DS records are modified to contain the private algorithm name,
allowing the validator algorithm to work the same for public and private
algorithms, or
2) The need and algorithm for fetching the private algorithm name from
the DNSKEY in a safe manner is documented somewhere (another RFC or
additional text), or
3) private algorithms are deprecated, or
4) everyone else decides that the current text is clear enough, there is
no need to change anything, we are fairly sure that future
implementations of private algorithm support will work just fine, thank
you very much.
Any of the above resolutions are acceptable, I think.
--
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/>