[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSEC3, version 13



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
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> 

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
scott.rose@nist.gov

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

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>