Subject: [dnsext] draft-ietf-dnsext-dnssec-bis-updates and NSEC3

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Dec 2008 19:51:18 -0800

The list traffic makes it sound like we all believe that NSEC3 is now really part of DNSSEC deployment. If so, draft-ietf-dnsext-dnssec-bis-updates should say so, given that we want that document to reflect reality. Humorously, that draft doesn't even *mention* NSEC3, despite the overlap in authors.

Proposals for draft-ietf-dnsext-dnssec-bis-updates:

- Add a new section 2.1 that describes NSEC3, says that it is expected to be used in many high-profile zones, and has been widely deployed in resolvers. Say explicitly that DNSSEC is now defined to include NSEC3, although it is expected that some resolvers will only handle NSEC until they are updated.

- Update current sections 2.1, 2.3, 2.4, 2.5, and 4.2 to indicate "NSEC and/or NSEC3" as appropriate.

- Change the status of the document to say that it updates 4033 as well.

- Add a new sub-section at the end of section 3 that says that RSA-SHA256 is now part of DNSSEC

- Add normative references to RFC 5155 and RFC-from-draft-ietf-dnsext-dnssec-rsasha256.

Do folks agree with this method of letting the world know that NSEC3 is required for DNSSEC?

--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: Alex Bligh <[email-masked]>
Date: Fri, 12 Dec 2008 10:39:06 +0000

--On 11 December 2008 19:51:18 -0800 Paul Hoffman <[email-masked]> 
wrote:

> If so, draft-ietf-dnsext-dnssec-bis-updates should say so, given that we
> want that document to reflect reality.

If we are taking the position that rsasha256 etc. should only get
one algorithm number, it seems to me that this is argument must
effectively be predicated on the belief that supporting NSEC3
in validators is required "in the real world" to exactly the same
extent as supporting NSEC. Given the above draft sets out what is required
"in the real world" (for the same value of "real world" as before),
I think +1.

Alex

---

From: "Blacka, David" <[email-masked]>
Date: Fri, 12 Dec 2008 11:22:50 -0500

On Dec 11, 2008, at 10:51 PM, Paul Hoffman wrote:

> The list traffic makes it sound like we all believe that NSEC3 is  
> now really part of DNSSEC deployment. If so, draft-ietf-dnsext- 
> dnssec-bis-updates should say so, given that we want that document  
> to reflect reality. Humorously, that draft doesn't even *mention*  
> NSEC3, despite the overlap in authors.

Heh, true.  Actually, the working copy I have does mention NSEC3, but  
that is because it contains a clarification to 5155 that was  
discovered in Minneapolis (Roy posted the basic text that I added).   
So, the next version will also update 5155 (unless the WG objects, of  
course).

> - Add a new section 2.1 that describes NSEC3, says that it is  
> expected to be used in many high-profile zones, and has been widely  
> deployed in resolvers. Say explicitly that DNSSEC is now defined to  
> include NSEC3, although it is expected that some resolvers will only  
> handle NSEC until they are updated.
>

I think I would be more inclined to add this sort of thing to a new  
section, personally.  I don't really see it in the same vein as the  
other "Significant Concerns".  Instead, these are updates to 4033  
section 10, expanding the DNSSEC Security Document Family.  But, I can  
be flexible.

--
David Blacka                          <[email-masked]>
Sr. Engineer                   Platform Product Development

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 12 Dec 2008 11:31:06 -0500 (EST)

> handle NSEC until they are updated.

You might be amused to know that such text already exist in the doc's 
XML source, just commented out.  In -04 and previous versions, this 
document proposed cataloging all known changes to 4033-5, including 
4470 and NSEC3.  Presumably 4955, 5011, and 4509 could be included now 
as well.  I'm not recalling why we never included that text -- it may 
have been that someone objected to expanding the scope of bis-updates.

As to whether we should including this, doc editor hat off: probably. 
Doc editor hat back on: rather than fold this into the existing 
section 2 or 3, I'm inclined to add a new section cataloging the 
changes made in other documents.

> "NSEC and/or NSEC3" as appropriate.

Absolutely, except not in 2.5 (that error is specific to NSEC).

> - Change the status of the document to say that it updates 4033 as well.

Why?

-- Sam

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Dec 2008 10:08:23 -0800

At 11:31 AM -0500 12/12/08, Samuel Weiler wrote:
>As to whether we should including this, doc editor hat off: probably. Doc editor hat back on: rather than fold this into the existing section 2 or 3, I'm inclined to add a new section cataloging the changes made in other documents.

I'm OK with that as well, but to a naive reader, that will not feel like "NSEC3 is a full member of the DNSSEC family".

>>- Change the status of the document to say that it updates 4033 as well.

Because 4033 talks about the parts of DNSSEC, and we are adding a new part. Section 8 of 4033 is inherently being updated to say "NSEC and/or NSEC3" in many places.

--Paul Hoffman, Director
--VPN Consortium