Subject: NSEC3 Issue 8: NSEC3 Signaling Mechanism

From: Geoffrey Sisson <[email-masked]>
Date: Tue, 21 Feb 2006 18:25:26 GMT

Issue:

Should a name server for a DNSSEC zone that uses NSEC3 RRs only somehow
signal this to NSEC3-unaware DNSSEC applications?

Example: if an NSEC3-unaware validating resolver queries for a
non-existent RRset in an NSEC3 zone, the response will contain one or
more NSEC3 RRs in place of the expected NSEC RR(s).  In RFC 4035,
omission of NSEC RRs in a No Data/Name Error response is a protocol
violation [Section 3.1.3]; consequently, the resolver will mark it
bogus.

Discussion:

Several approaches have been considered for handling this:

1.  Use a full type code rollover (a.k.a. `DNSSECter')

    - Fully independent DNSSEC scheme (third one, if RFC 2535 is
      considered).

    - Four new RRs:

        DNSKEY -> DNSKEY2
        RRSIG  -> RRSIG2
        NSEC   -> NSEC3
        DS     -> DS2

    - All RR formats identical except for NSEC vs NSEC3

    - NSEC3-unaware validators see only DNSSECbis RRs.  In NSEC3 zones
      only new RRs are used.  Either or both validation schemes may be
      used independently without reference to one another.

    However:

    - A validating resolver must have special (non-RFC 4033-35) rules
      for recognising and processing DS2 RRs in DNSSECbis zones, e.g.
      when a DNSSECter-only zone has a DNSSSECbis-only parent.
      Otherwise the DS2 RR will not be identified as part of any
      validation chain.  So while a type-code rollover may at first
      glance appear to be an elegant solution, it only works if one or
      another set of type codes is used exclusive     DNSSECbis zone.

    - If the KSK of the NSEC3 is a trust anchor, care must be taken not
      to use it in the `trusted-keys' store of a non-NSEC3-aware
      validating resolver.

3.  Use a new DS message digest number

    - Use the DS message digest field for signaling both:

        a. that NSEC3 is in use in the child zone, and

        b. which hash algorithm is in use by the NSEC3 RRs in the
           child zone.

     - Proposed in this post to namedroppers:

    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.

4.  Use an unknown algorithm identifier

    - Described in draft-ietf-dnsext-dnssec-experiments-01.txt

    - Use algorithm identifiers in RRSIG and DS RRs that would not be
      recognised by NSEC3-unaware validating resolver, so that
      No Data/Name Error responses would appear insecure rather than
      bogus.

    However:

    - Would require the use of multiple algorithm identifiers for the
      same algorithm, at least until NSEC3 was folded into a revised
      version of DNSSECbis.  This would mean SHA-1 (and probably
      SHA-256) would have two identifiers each.  This is mitigated by
      the fact that:

      -  the algorithm identifier is an 8-bit number out of which
         only 10 assignments have been made:

             http://www.iana.org/assignments/dns-sec-alg-numbers

      -  The rate of new assignments is expected to be low.

5.  Do nothing

    No Data/Name Error responses for queries that have NSEC3 somewhere in
    the validation chain will be marked bogus.

    - If DNSSEC deployment is sufficiently minimal before NSEC3 (or
      other NSEC++) is available, this may have a negligible impact.

    However:

    - DNS operators considering the deployment of DNSSEC might choose
      to wait until NSEC3 is available, or, conversely,

    - DNSSEC deployment might become sufficiently advanced that
      operators will be unwilling to deploy NSEC3.

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.

--
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: Mark Andrews <[email-masked]>
Date: Wed, 22 Feb 2006 13:34:20 +1100

> Several approaches have been considered for handling this:
 
	[snip]

>       trust is NSEC -> NSEC3 -> NSEC then the NSEC descendant will

	Incorrect.  A correctly functioning RFC 4035 validator will
	treat the child (NSEC3) zone as insecure.  Any children of
	a insecure zone are insecure.

	Mark
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Roy Arends <[email-masked]>
Date: Wed, 22 Feb 2006 10:09:45 +0000

>    treat the child (NSEC3) zone as insecure. 

RFC 4035 does handle unknown algorithm but not unknown digest types 
(though digests could be seen as a subset of algorithms). This is 
described in bis-updates.

So, when a server responsible for an NSEC zone passes a delegation that 
contains a DS with unknown digest, to indicate the delegated child is 
NSEC3, a 4035 compliant resolver may fail to handle it as insecure, and 
might handle it as bogus.

>    Any children of

Yes. Any children of a bogus zone will never be seen, which is a lot 
worse.

Furthermore, if your trust anchor is a sep to a NSEC3 zone, there is no DS 
to signal that a zone is NSEC3. An rfc4035 compliant validator could be 
configured as such, hence there is yet another way to shoot oneself in the 
foot. If the 'signal' is embedded in the signing algorithm (as suggested 
in (4)), these points are resolved.

Roy

---

From: Mark Andrews <[email-masked]>
Date: Wed, 22 Feb 2006 21:36:49 +1100

> might handle it as bogus.

	In anycase NSEC -> NSEC3 -> NSEC will work with the digest fields
	as easily as with the algorithm field.  The however is incorrect.