Subject: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 09 Dec 2010 16:30:44 -0500

Dear colleagues

The chairs have received a request to adopt the following draft as a 
working group document.
http://tools.ietf.org/html/draft-hoffman-dnssec-ecdsa-04

The draft falls within the WG charter because it pertains to DNSSEC 
algorithm maintenance

The rules of the working group require that at least 5 members of the 
working group publicly state that they support adoption. If 5 people
have not stepped forward by January 15'th the draft will not be adopted.

Please read the document and say what changes are needed to get the 
document to be ready for advancement. The plan is to dispose of this
document in short order.
Please comment on if this document should be for informational or 
standards track.

	Olafur & Andrew
PS: as always dispose means in this context, advance or explicitly reject.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 11 Dec 2010 15:44:43 +0100

I am in favor of the adoption of this document but I have 3 major
questions/concerns:
 - IMHO the SHA-384 DS stuff should be put in another document:
  * there is no reason to mix SHA-384 DS with ECDSA DNSKEY/RRSIG
  * there is even no text explaining when SHA-384 should be used
   in this case
  * it makes easier to address the next item

 - if there is no 'strength order' between keys/signatures this is not
  the case for DS digest types. Today the only text using it is
  the section 6.1 of RFC 4509. Obviously it is no longer enough with
  more than 2 types, so IMHO we need a new/more general text about
  potential digest type downgrade attacks.

 - do ECDSAP256SHA256 and ECDSAP384SHA384 two variants of the same
 algorithm or different algorithms, i.e., it is allowed to use a
 ECDSAP256SHA256 zone signing key with a ECDSAP384SHA384 key signing key?
 Today this is not the case because algorithm numbers are different, so:
  * do we want to allow this?
  * in anycase a text should be added explaining it is (or it is not)
   allowed.

Thanks

[email-masked]

PS: using another hat, I have an implementation of a previous version
of the draft.

---

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 13 Dec 2010 13:13:35 -0500

I have read the draft and I am in favor of adoption.

Also:

>  * it makes easier to address the next item
While "single serving" Internet Drafts can get annoying (with an explosion of references to track), I think it might be a good idea to remove the discussion of SHA-384 for DS hashes.  

>  * in anycase a text should be added explaining it is (or it is not)
They are related, much like RSASHA1 and RSASHA256, but since they would have different algorithm codes, they must be treated as different algorithms in DNSSEC as per RFC 4035.  

Like the SHA-384 for DS RR discussion, I don't think this draft should be the place to discuss clarification (or desired changes) of the text in RFC 4035 that discusses multiple algorithm use in a zone.

Scott

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 21 Dec 2010 11:50:40 +0100

Read it, in favor of adoption.

Matthijs