Re: private algorithms and the DS record

[Rob Austein <sra@isc.org>]

At Wed, 22 Dec 2004 12:13:30 -0500, David Blacka wrote:
> 
> Why would a validator ever match a DS with an unknown algorithm to a
> DNSKEY?

If the validator knows that it supports at least one private
algorithm, it needs to figure out whether it supports the particular
private algorithm(s) in question.  The information that the validator
needs to do this is available, but it's not all in the DS RRset: some
of it is in the DNSKEY RRset, so the validator needs to retrieve and
examine the DNSKEY RRset too.

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

Current implementations think that they know how to generate the DS
hash for any DNSKEY RR.  You propose to break that.

Whether there are any current implementations of private
algorithms...I'm not aware of any, but, by definition, nobody would
have to tell either you or me if there are any, would they?

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

Doing it my way, the code currently in the field could support this
with no changes.  Implementations that don't support any private
algorithms at all can bail out based just on the algorithm number from
the DS RRset; implementations (if any) that do support private
algorithms can retrieve the DNSKEY and check the private algorithm
identifier of the DNSKEY that matches the DS hash.

Doing it your way, everybody has to know how to do the new DS
calculation algorithm.  I still don't see why we need this.

> If, in the future, implementations add private algorithm support,
> why wouldn't they be able to understand this extension?

If we change the protocol to include this extension, of course they
would, but it's not necessary.

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

I've read all of this, more than once.  You still haven't answered my
question: please show me the text that forbids the validator from
retrieving the DNSKEY RRset as part of figuring out whether it
supports the agorithms listed in the DS RRset.  -protocol 5.2 doesn't
specify -how- the validator performs this check.  You appear to be
assuming that the validator is only allowed to do a byte equality test
on the algorithm number and is not allowed to think harder if the
algorithm number is itself subtyped.  No, wait, you do want it to be
allowed to think harder if it's subtyped, because if it's one of the
private algorithm numbers you want it to do an extra check.  Ok, so
why is your extra check (that requires a protocol change) better than
mine (which doesn't)?  I don't get it.

Please try re-reading section 5.2 yourself, ok?  :)

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

No doubt, had we had this discussion before approving the documents,
we would have added more text on this subject.  I don't mind writing
more text now either.  I do object to changing the protocol, since I
see no need to do so in this case.

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

Sounds like there's a clarification draft to write. I never much liked
leaving the whacky private algorithm stuff in the base spec anyway,
but the WG said to keep it when the editors asked, so we did.  A
separate draft explaining how to use private algorithms would be fine.
Just please don't change the base protocol.

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

Right.  So one of two things happens in the case under discussion:

a) The validator knows that it understands zero private algorithms.
   Trivial, give up, we're done.

b) The validator knows that it understands at least one private
   algorithm.  In this case, the validator has to retrieve the DNSKEY
   RRset and check the DS hashes so that it can extract the private
   algorithm identifiers from the DNSKEY RRs corresponding to the
   private algorithm subset of the DS RRset.   Painful, but doable.
   After performing this check, the validator knows whether it
   supports the algorithms listed in the DS RRset or not.  Done.

> I am in no way wedded to the idea of modifying the format of the DS
> RR.

Good.

> It just looks like the easiest way to solve the problem that I am
> concerned about.

Guess we'll have to agree to disagree here.

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

I think they would, but the implementor would have to do everything
right, and it's pretty clear that there's some text we should write to
help the implementor do it right.

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

You keep saying that, and I keep not seeing it in the text.  Please
show me where it says "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*.

Right.  It's implied (well, I think it is, your mileage clearly
varies), but it's not obvious, and I agree that we should fix that.

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

No, you're probably right about that.  It was your proposed solution
(a protocol change) that bothered me, not your problem analysis.

> 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

Please no.

> 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

Ok with me.  I prefer not to mess around with nontrivial content
changes as RFC Editor note or AUTH48 hacks, so I'd prefer a separate
document.

> 3) private algorithms are deprecated, or

Well that would be ok with me, but the WG wanted to keep this glorp
the last time we asked.

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

I think some clarification is in order.  I just don't think it
requires either a protocol change or a last minute change to the
documents we already handed off to the RFC Editor.

> Any of the above resolutions are acceptable, I think.

So I think we agree, except on option (1).

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