Subject: Re: NSEC3, version 13

From: "Olaf M. Kolkman" <[email-masked]>
Date: Sat, 1 Dec 2007 17:46:15 +0100

On 30Nov 2007, at 6:43 AM, Ólafur Guðmundsson /DNSEXT chair wrote:

> Please speak up if this change is of concern to you.
> If no one speaks up by Dec 7'th I will tell our AD the changes are
> fine.

So the change is that the basic-4 steps procedure was removed and  
replaced with text that amounts to "We'll solve this when we get to  
this".

For those who are not up to speed with the issue that is being  
addressed, the thread causing all this starts here:
http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00553.html

To me it is clear that the current text postpones dealing with the  
problem that starts with the premisses in Sam Weiler's observation:
    "but we aren't (as far as I can tell) requiring that an NSEC3- 
SHA256-capable resolver also support NSEC3-SHA1"

If the requirement to support old algorithms would exist, then the  
rollover is one that we currently understand.

Personally I could imagine that the introduction of a new hashing  
algorithm would be able to deal with that requirement: If all else  
fails using the blunt instrument of a flag date. Hopefully there is a  
more elegant way. Finding resolvers not supporting the old algorithm  
is unlikely but I appreciate the fact that a corner case remains a  
corner case and will need to be dealt with.

Anyhow, as far as I am concerned, this is a corner case that can be  
dealt with later. The current text does sufficiently flag this is an  
issue and I am confident there is at least one blunt way to solve the  
issue.

In other words I am supportive of this change.

No hats.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Alex Bligh <[email-masked]>
Date: Tue, 04 Dec 2007 09:06:50 +0000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> If no one speaks up by Dec 7'th I will tell our AD the changes are

FWIW this text does NOT concern me and I think the changes are fine.

Alex

--
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: Peter Koch <[email-masked]>
Date: Sat, 8 Dec 2007 08:07:16 +0100

> replaced with text that amounts to "We'll solve this when we get to  

I agree with the changes proposed for -13 in Roy's message dated 30 NOV.

> SHA256-capable resolver also support NSEC3-SHA1"

This is one underlying assumption, although it doesn't _have_ to be
that way.  The new algorithm could as well mean "SHA256 or SHA1".
Theoretically this would allow a downgrade attack, but that could be
mitigated by doing a double transition (where the intermediate state
might even be infinitesimally small):
	NSEC3-SHA1 -> NSEC3-SHAng-or-SHA1 -> NSEC3-SHAng
Alternatively, for the transition phase, both hash algs could be signalled
in the DS RR.  Either of these could again have corner cases, but locating
and arguing them is not my point.  I am confident that the WG as a whole
understands signalling and rollover well enough to address the issue
once it becomes necessary. Hash algorithm is expected to be a _rare_
event, as opposed to key rollover, so extra manual intervention or
timing constraints appear acceptable IMHO.
The exact scheme will also depend on the operational environment at that
future date and thus could be dealt with later better anyway.

> issue and I am confident there is at least one blunt way to solve the  

Seconded. Please make -13 happen.

-Peter

---

From: Scott Rose <[email-masked]>
Date: Mon, 10 Dec 2007 15:27:37 -0500

I have read over the changes, and I believe that NSEC3 deployment will
be a minority of DNSSEC deployment (which will be a minority of DNS).
Those that do NSEC3 and wish to do any type of transition will be
competent enough to know how best for their zone to transition, which
would likely be different from anything written in a static RFC.

It is most likely to be a rare event (as Peter Koch mentioned in a
previous email) - I can really only think of 1 (maybe 2) hash algorithms
beyond SHA-1 that may be used in the future (SHA-256 for example).

I think the text is acceptable as it stands, and would like the -13
version to progress.

Scott

Roy Arends wrote:
> Dear WG,
> 
> This is the latest version of the NSEC3 draft, version 13.
> 
> Since the submission deadline for IETF 71 has passed, I've put the latest 
> version online:
> 
> http://www.nsec3.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/draft-ietf-dnsext-nsec3-13.txt?format=raw
> 
> This version addresses the NSEC3 hash algorithm agility issue.
> 
> Changes are:
> 
> 1) Section 12.1.3 has been replaced with the following text:
> 
> 12.1.3.  Transitioning to a New Hash Algorithm
> 
>    Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
>    parameter, this document does not define a particular mechanism for
>    safely transitioning from one NSEC3 hash algorithm to another.  When
>    specifying a new hash algorithm for use with NSEC3, a transition
>    mechanism MUST also be defined.  It is possible that the only
>    practical and palatable transition mechanisms may require an
>    intermediate transition to an insecure state, or to a state that uses
>    NSEC records instead of NSEC3.
> 
> 2) an addition to the IANA considerations:
> 
> 11. IANA Considerations 
>  
>    Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm 
>    parameter, this document does not define a particular mechanism for 
>    safely transitioning from one NSEC3 hash algorithm to another. When 
>    specifying a new hash algorithm for use with NSEC3, a transition 
>    mechanism MUST also be defined.
> 
> 3) One typo was fixed, and two of the authors' addresses have changed
> 
> Regards,
> 
> Roy Arends
> Nominet UK
> 
> --

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------