Subject: Re: NSEC3 Issue 8: NSEC3 Signaling Mechanism

From: Sam Weiler <[email-masked]>
Date: Fri, 17 Mar 2006 16:45:34 -0500 (EST)

On Tue, 21 Feb 2006, Geoffrey Sisson wrote:

> Should a name server for a DNSSEC zone that uses NSEC3 RRs only somehow
> signal this to NSEC3-unaware DNSSEC applications?
...
> 3.  Use a new DS message digest number
...
>    http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01087.html
>
>    However:
>
>    - Only works if all subsequent children are NSEC3.  If the chain of
>      trust is NSEC -> NSEC3 -> NSEC then the NSEC descendant will
>      appear bogus.

I concur with Mark -- assuming a correct implementation, the NSEC 
descendant will be treated as insecure.  Unless real legacy code does 
the Wrong Thing (tm) with unknown message digests, the omission of 
this detail from 403{3,4,5} is not a showstopper here.

> 4.  Use an unknown algorithm identifier
....
> Proposed Resolution:
>
> Approach #4 appears to be the most promising.  Thorough testing will be
> required to determine whether any non-obvious issues exist, though it's
> been shown to work in previous testing.

While I'm pretty confident in the viability of #4, I'm also pretty 
confident in #3.  I also think it's wisest for us to use the less 
populated and slower growing registry.  While the hash function 
registry will be more populated over the time, the algorithm registry 
could grow as the product of hash function changes and public key 
signing algorithm changes -- let's not put further pressure on the 
algorithm number registry by using it for this signaling.

So, again, unless we find a showstopper with #3, I think we should 
stay there.

-- Sam

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>