Re: private algorithms and the DS record

[David Blacka <davidb@verisignlabs.com>]

Alex Bligh wrote:
> --On 21 December 2004 10:49 -0500 Samuel Weiler <weiler@tislabs.com> wrote:
>
> > As for updating the docs, I also prefer an RFC Editor note rather than
> > a separate doc.
>
>
> (From a position of relative ignorance) yes I agree - assuming we are
> confident we have infact bottomed the problem out as the worst thing
> to do would be to half fix it.

Perhaps I am now suddenly confused.  What is "half fix it"?

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.

2) Ed pointed out a possible security problem.

3) Sam argued that this security problem (if it exists) would be hard to 
exploit.

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?

I am personally of the opinion that the fact that the DS was omitted was 
just an oversight, due to the fact that no one really examined private 
algorithms during the main review process.  I am of the opinion that NOT 
fixing this means, at the very minimum, that private algorithm support 
will be harder than necessary to implement in the validator.  It *may* 
mean that private algorithms are unusable or at least unsafe.

And I am unsure where the concept that putting the private algorithm 
label in the DS record only "half" fixes the problem comes from.  Or why 
it would be seen as any more of a hack in DS than in DNSKEY or RRSIG.

If, as I suspect, this was a simple oversight, then of course an RFC 
Editor note is the correct approach.

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