Subject: [dnsext] Contradictions in NSEC3 wording in draft-ietf-dnsext-dnssec-rsasha256

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Apr 2009 08:57:45 -0700

Greetings again. draft-ietf-dnsext-dnssec-rsasha256 is probably not ready for IETF Last Call. I have read it again more carefully because I am preparing some other related drafts, and the coverage of NSEC3 is contradictory to the point where I can't figure out what is wanted.

For reference:

==========================================================
5.2.  Support for NSEC3 Denial of Existence

   RFC 5155 [RFC5155] defines new algorithm identifiers for existing
   signing algorithms, to indicate that zones signed with these
   algorithm identifiers can use NSEC3 as well as NSEC records to
   provide denial of existence.  That mechanism was chosen to protect
   implementations predating RFC5155 from encountering resource records
   they could not know about.  This document does not define such
   algorithm aliases, and support for NSEC3 denial of existence is
   implicitly signaled with support for one of the algorithms defined in
   this document.

5.2.1.  NSEC3 in Authoritative servers

   An authoritative server that does not implement NSEC3 MAY still serve
   zones that use RSA/SHA-2 with NSEC denial of existence.

5.2.2.  NSEC3 in Validators

   A DNSSEC validator that implements RSA/SHA-2 MUST be able to handle
   both NSEC and NSEC3 [RFC5155] negative answers.  If this is not the
   case, the validator MUST treat a zone signed with RSA/SHA-256 or RSA/
   SHA-512 as signed with an unknown algorithm, and thus as insecure.
==========================================================

There are two sets of contradictory statements:

a) Mandatory support
"support for NSEC3 denial of existence is implicitly signaled with support for one of the algorithms defined in this document"
vs.
"An authoritative server that does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 with NSEC denial of existence."

b) Confused MUST
"A DNSSEC validator that implements RSA/SHA-2 MUST be able to handle both NSEC and NSEC3 [RFC5155] negative answers"
vs.
"If this is not the case..."

In both cases, the second statement is impossible based on the first statement.

In order to increase clarity, I propose that 5.2 be rewritten, without subsections, as follows:

5.2.  Support for NSEC3 Denial of Existence

   RFC 5155 [RFC5155] defines new algorithm identifiers for existing
   signing algorithms, to indicate that zones signed with these
   algorithm identifiers can use NSEC3 as well as NSEC records to
   provide denial of existence.  That mechanism was chosen to protect
   implementations predating RFC5155 from encountering resource records
   they could not know about.  This document does not define such
   algorithm aliases.

   A DNSSEC validator that implements RSA/SHA-2 MUST be able to
   handle both NSEC and NSEC3 [RFC5155] negative answers.  An
   authoritative server that does not implement NSEC3 MAY still serve
   zones that use RSA/SHA-2 with NSEC denial of existence.

--Paul Hoffman, Director
--VPN Consortium

--
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: Mon, 20 Apr 2009 21:01:01 -0400 (EDT)

> ... the coverage of NSEC3 is contradictory to the point where I 
> can't figure out what is wanted.
...
> a) Mandatory support

I don't see the problem with a).

> b) Confused MUST
> "A DNSSEC validator that implements RSA/SHA-2 MUST be able ...
> vs.

I see your point, but I like the clarification in the existing text.

I think the existing text is fine.  But I'm also OK with the proposed 
edits.

-- Sam

---

From: Florian Weimer <[email-masked]>
Date: Tue, 21 Apr 2009 15:52:56 +0200

>    handle both NSEC and NSEC3 [RFC5155] negative answers.

Does "handle" mean that it's okay to treat an NSEC3-protected negative
answer as insecure (as opposed to bad)?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 21 Apr 2009 16:16:32 +0200

> answer as insecure (as opposed to bad)?

that would mean treating part of a signed zone different than the rest of it... 
so no.

Jelte

---

From: Florian Weimer <[email-masked]>
Date: Tue, 21 Apr 2009 16:28:27 +0200

* Jelte Jansen:

> that would mean treating part of a signed zone different than the rest
> of it... so no.

Then you should write "validate", I think.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Apr 2009 09:35:19 -0700

>Then you should write "validate", I think.

That works for me.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 23 Apr 2009 14:37:39 +0200

>> Then you should write "validate", I think.

I have heard no other plusses or minuses, and I like the text, so I'll submit an 
update shortly. There will also be another addition as a gift from your editor.

Jelte