Subject: comments on nsec3-02

From: Samuel Weiler <[email-masked]>
Date: Sat, 23 Jul 2005 12:16:29 -0400 (EDT)

Having compared nsec3-02 to -01, I only found a few substantive
changes.  If I've missed any, I hope someone will point them out.
The ones I spotted were:

  -- resolver instructions WRT wildcards, in 6.2

  -- identity hash number allocated, in 8 (but not described anywhere)

  -- truncation signaling method, last paragraph of 6.4.3

Everything else I saw was editorial (perhaps important, but not
changing the protocol in any way).  Again, if I missed something,
please let me know.  I'm most concerned by a couple of missing pieces,
and I'll send a separate message suggesting a way forward for each:

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

     I remember discussing the above at some length on the list, and I
     think we concluded that we'd require a set of mandatory
     algorithms (maybe even just one) and anything outside that list
     would be treated as a protocol violation.  Unfortunately, this
     draft still has an IANA registry for these numbers (and still
     doesn't specify an assignment policy), which suggests that new
     algorithms might be added later -- we need to tighten this up.
     http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00492.html
     http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00581.html

And, lastly, I'm surprised by:

  -- the continued inclusion of opt-in (the authoritative-only bit).

I haven't gone through the doc with a fine-toothed comb yet.  I'll
send more detailed comments later.

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

---

From: Samuel Weiler <[email-masked]>
Date: Sat, 23 Jul 2005 12:41:09 -0400 (EDT)

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