Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-11.txt

From: Jelte Jansen <[email-masked]>
Date: Wed, 04 Mar 2009 09:26:56 +0100

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the DNS Extensions Working Group of the IETF.
> 
> 
> 	Title           : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
> 	Author(s)       : J. Jansen
> 	Filename        : draft-ietf-dnsext-dnssec-rsasha256-11.txt
> 	Pages           : 8
> 	Date            : 2009-02-27
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-11.txt
> 

this draft I submitted last week contains a bit of text about the use of the
term SHA-2, as proposed by Ed. I also updated the text of section 5 to be more
clear, but I decided not to include the tables provided by Mark, as in my
opinion, they would suggest that this draft would update the handling of
existing algorithms. Leaving those out would reduce the table to exactly the
text above, and that seemed unnecessary.

So please take another look, i think it's about done now.

For your convenience, a wdiff of 10-11 can be found here:

http://nlnetlabs.nl/downloads/publications/draft-ietf-dnsext-dnssec-rsasha256-wdiff-10-11.html

Jelte

--
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: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Mar 2009 10:53:50 -0400

Dear colleagues,

> So please take another look, i think it's about done now.

I note we haven't had any discussion of this text since Jelte posted
the draft.  Those who objected during WGLC are especially requested to
comment.  I'd like to send this draft to the IESG, per our previous
plan.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Mar 2009 08:10:34 +1100

> comment.  I'd like to send this draft to the IESG, per our previous

	Replace "use NSEC3 instead of NSEC records" with
	"support NSEC3 as well as NSEC".

   RFC5155 [RFC5155] defines new algorithm identifiers for existing
   signing algorithms, to indicate that zones signed with these
   algorithm identifiers use NSEC3 instead of 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.

   RFC5155 [RFC5155] defines new algorithm identifiers for existing
   signing algorithms, to indicate that zones signed with these
   algorithm identifiers support 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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 Mar 2009 11:29:30 -0400

Looking at http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-rsasha256-11

In the IANA considerations:

# 6.  IANA Considerations
#
#   This document updates the IANA registry "DNS SECURITY ALGORITHM
#   NUMBERS -- per [RFC4035] "
#   (http://www.iana.org/assignments/dns-sec-alg-numbers).  The following
#   entries are added to the registry:
#
#                                                     Zone
#   Value      Algorithm               Mnemonic    Signing  References
#   {TBA1}   RSA/SHA-256              RSASHA256          y {this memo}
#   {TBA2}   RSA/SHA-512              RSASHA512          y {this memo}

The IANA registry (I just happened to be looking at it) has these columns:

% "Number" "Description" "Mnemonic" "Zone Signing" "Trans. Sec." "Reference"

I.e. - the document is missing direction to IANA on whether these are 
okay for "transaction security."  (I assume it's "Y" for both.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 11 Mar 2009 13:49:27 -0400

> okay for "transaction security."  (I assume it's "Y" for both.)

hmm, that column also appears to be missing in 4034. It is an
interesting one (as is the spelling of 'zone zigning');

Are rsa/sha-1 and friends used for TSIG/SIG(0) (well, obviously not for
tsig)?

And how does RSA-NSEC3-SHA-1 fit into that? Why does that row has a Y
for transaction security?

Maybe the whole registry needs a cleanup...

Jelte

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 Mar 2009 14:22:40 -0400

>Maybe the whole registry needs a cleanup...

I've already requested a re-ordering of them (so at least the 
Delegation Signer registries appear closer to the rest of the DNS; 
not to mention IDN...).

It's pretty much up to the WGs involved to keep the registries 
cleaned up.  That's what 2929bis was partly about and some quibbling 
over security algorithms earlier.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468