Subject: [apps-discuss] APPSDIR Review of draft-ietf-dnsext-ecdsa-04

From: William Mills <[email-masked]>
Date: Mon, 6 Feb 2012 21:46:43 -0800 (PST)

Document: draft-ietf-dnsext-ecdsa-04

Title: Elliptic Curve DSA for DNSSEC

Reviewer: William J. Mills

Review Date: February 6th, 2012

IETF Last Call Date: NA

IESG Telechat Date: NA

Summary: This draft informational RFC is ready for publication subject to correcting one major issue.
Caveats: I'm not a DNS expert, so while this looks right to me there may be something obvious that I missed.

Major Issues: 

Section 4 paragraph 2: While this is an informational RFC, "The two integers, each of which is formatted as a simple octet string, are combined into a single longer
   octet string ..." is not well enough defined.  The examples are base64 encoded and it looks like what we have there is for instance 2 48byte integers concatenated.  

This document should do one of:
-    quote the normative language from the appropriate specification for how these integers are to be formatted
-    cite the normative specification explicitly in this paragraph
-    if there is no normative language already then this spec is going to have to become normative (not likely)

Minor Issues: [list any minor issues such as text that is unclear or confusing, preferably by section number] 

Section 1 paragraph 5:

Is the computational difference here simply informational?  If so it might want to move out of the introduction. 

If the computation cost is 
meaningful then that impact should probably be discussed a little more (probably in a new section?) 
so the implementer can make an informed choice about what will be right 
for their use case.  Presumably the signatures could actually be computed once per zone file load, that probably depends on the implementation.  Similar savings can probably be had on the client doing a lookup, caching the previous values and checking against the returned signature so the validation only need be done once per item.  

Nits:

None.