Subject: dnssec-records ISSUE: don't make NSEC a protocol requirement

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Jun 2004 10:56:09 +0200

(I'm trying to get some issues entered into the issue tracker, since
they might be lost in the flood of messages on the list otherwise..)

Transition to DNSSEC-ter difficulty caused by DNSSEC-bis requirement for NSEC.

name: Simon Josefsson
email: [email-masked]
Date: June 22
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01161.html
Type: T
Priority: W

Document: draft-ietf-dnsext-dnssec-records-08
Section: 2.3

Rationale/Explanation of issue:

Recent posts make it clear that people believe DNSSEC-ter and
DNSSEC-bis is intended to co-exist.  If DNSSEC-ter is supposed to
solve the zone walking issue, I don't think this will be possible
given current text in DNSSEC-bis.  It says:

   Each owner name in the zone which has authoritative data or a
   delegation point NS RRset MUST have an NSEC resource record. The
   process for constructing the NSEC RR for a given name is described in
   [I-D.ietf-dnsext-dnssec-records].

So any zone not including NSEC's for all owner names violate the
protocol, and a DNSSEC-bis resolver somehow detecting this situation
is allowed to regard the zone as bogus.

Requested change:

The simple part is to change MUST into SHOULD above, and add the
following security consideration:

  When NSEC's are not provided for all owner names in a zone, perhaps
  to prevent zone walking, resolvers will not be able to verify
  negative proofs.  Further, if a all-inclusive NSEC is added, it may
  be used in a replay attack to prove non-existence of existing names.

The document must also require behaviour on resolvers that encounter
absent NSEC's, and this is where it get complicated.  I proposed
something like:

   If a resolver do not receive expected NSEC's to a query, it MUST
   NOT assume the zone is bogus, but instead assume negative proofs
   are absent.

But there may be other changes needed as well.

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