NSEC3 signalling mechanism

[Samuel Weiler <weiler@tislabs.com>]

On Sat, 23 Jul 2005, Samuel Weiler wrote:

>   -- the lack of specification of a signaling mechanism for indicating
>      that NSEC3, rather than NSEC, is in use.  I think we agreed this
>      could be deferred, but the selection is necessary for
>      implementation to go forward.
>
>   -- the lack of clarity re: which hash algorithms are
>      required/mandatory and/or a way to signal which may be in use in
>      a given zone, which may be needed to prevent a downgrade attack.
>      (Or drop to a single algorithm, and remove the field.)

dnssec-trans-02 recommends a partial typecode roll, rolling the NSEC
and DS types as well as the DNSSEC-OK bit.  As I recall the joy of
finding a new protocol bug every two months in late 2002 with DS, I
find myself longing for something else.

I propose:

We use the DS message digest number field for signaling BOTH:
  1) that NSEC3 is in use in the child zone, and
  2) which SINGLE hash algorithm is used by those NSEC3 RRs.

This requires a new DS message digest assignment (in a Standards
Action registry), whether using SHA-1, as before, or something new.
It also depends on resolvers treating DS's with unknown digest
algorithms as they would DS's with unknown public key algorithms,
which is not described in 4035, but is described in bis-updates
section 3.1.

We could also then remove the NSEC3 hash algorithm field along with
the need to have rules for handling unknown values in that field.
Simiplicity is a good thing.  It also removes the need for a new IANA
registry.

-- Sam

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