Re: private algorithms and the DS record

[Rob Austein <sra@isc.org>]

At Tue, 21 Dec 2004 12:27:42 -0500, David Blacka wrote:
> 
> Let me summarize this issue as I see it:
> 
> 1) I pointed out an issue of symmetry: in this one case, a validator 
> cannot make the same decision at the same algorithmic point as it can 
> without private algorithms.  That is, it cannot decide to treat the 
> subzone as unsigned from the DS set alone, it must fetch the DNSKEY to 
> find the full name of the algorithm.  I see this as an implementation 
> problem.  Something that might work, but is an unnecessary complication, 
> and a complication that isn't clearly visible from the documents.

I think what you've detected is an optimization that can't be
performed in the case of private algorithms.  The original purpose of
the algorithm check on the DS RRset was to defend against algorithm
downgrade attacks (your points 2 and 3).  I do not see it as a big
deal that one has to retrieve the child's apex DNSKEY RRset before one
can figure out whether one really understands the algorithm in use.

The private algorithms are specified as subtypes of a subtype.  You
should expect them to be a horrible mess.

> 2) Ed pointed out a possible security problem.
> 
> 3) Sam argued that this security problem (if it exists) would be hard to 
> exploit.

I think that Sam and Scott have demonstrated that this is not in fact
a serious problem, since the DS hash covers the algorithm ID.

There may be an algorithm downgrade attack issue if somebody uses two
separate private algorithms in the same zone.  Maybe not.  Haven't
analyzed it in detail.  Am not convinced we should be losing sleep
over it.

> Let's approach this issue from the opposite direction.  Is there any 
> reason NOT to prepend the private alg. name to the DS hash?  Was the 
> fact that the DS wasn't mentioned in the private algorithm appendix ON 
> PURPOSE?

If I understand what you're proposing, it would special-case the
private algorithm subtype, ie, the DS RR would now be doing special
voodoo for the private algorithm subtypes.  The situation is not
equivilent to the situation with DNSKEY and RRIG -- in the latter
cases, the special-case voodoo was inserted into a field that's
algorithm-specific in any case (key material or sig material,
respectively).  In the DS case, if I understand you correctly, you're
proposing to insert the special-case voodoo into a field that's the
same for every (signature) algorithm (hash of the key material).

I don't think we should do this to the DS RR.  It already hashs the
private algorithm identifier information as part of the key material,
that should suffice.

So, to answer your question, while I don't think there was a concious
decision here (don't think anybody thought much about it), I think the
algorithm as specified is correct.

If you do manage to convince the WG to change this, we'll probably
need to do the equivilent of TCR to the private algorithm subtypes.

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