DNSSEC Operational Practices
draft-ietf-dnsop-dnssec-operational-practices-08

[Ballot discuss]
This document will obsolete RFC 2541.  What has changed?
  Please add a section to tell the reader.

  Section 3.4 says:
  >
  > As the MD5 hashing algorithm is showing (theoretical)
  > cracks, we recommend the usage of SHA-1.
  >
  The "cracks" in MD5 are not theoretical.  When collision resistance
  is needed, as is the case here, there are real concerns.  SHA-1 is
  not meeting its design goal, but NIST says that it is acceptable
  until 2010.  So, I agree with the recommendation, but I request
  that you drop "(theoretical)".

[Ballot discuss]
This document will obsolete RFC 2541.  What has changed?
  Please add a section to tell the reader.

  Please add a statement to the Abstract that indicates that the
  document will obsolete RFC 2541.

  Section 3.4 says:
  >
  > As the MD5 hashing algorithm is showing (theoretical)
  > cracks, we recommend the usage of SHA-1.
  >
  The "cracks" in MD5 are not theoretical.  When collision resistance
  is needed, as is the case here, there are real concerns.  SHA-1 is
  not meeting its design goal, but NIST says that it is acceptable
  until 2010.  So, I agree with the recommendation, but I request
  that you drop "(theoretical)".

  Section 3.5 says:
  >
  > Assuming this rich attacker will not attack your key and that
  > the key is rolled over once a year, we come to the following
  > recommendations about KSK sizes; 1024 bits low value domains,
  > 1300 for medium value and 2048 for the high value domains.
  >
  1536 is the usual in-between point (not 1300).  Why the unusual
  choice here?  Also, I have seen very little implementation for any
  sizes between 1024 and 2048 for key generation; however, the
  signature validation with such a key should not cause trouble.

[Ballot comment]
A citation such as "Please see [RFC4033] for an introduction to DNSSEC and its
requirements" would be helpful.

The full Gen-ART review by Elwyn Davies with some nits is posted at
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-dnsop-dnssec-operational-practices-07-davies.txt

[Ballot comment]
I agree that if followed, the advice in this document would produce
secure DNS deployments.  I wonder though whether this isn't one of
those cases where great security is the enemy of any security at all.
I read this advice and can't help but thinking that perhaps secure DNS
just isn't worth the bother of all that work--especially without tools
to do it for me.  And the tools can't really help much if I'm really
going to follow all that advice about air gaps for my keys.  Perhaps
the advice here is appropriate for Google and Microsoft and the root.
I think it's overkill for me and any of the startups I've worked at.
I think that even if I had really long-lived signatures and rarely did
rollover I'd have something significantly better than I do today.  I
wish we did a better job of balancing the security advice we give.

[Ballot comment]
One comment from the Gen-ART reviewer is: why not BCP? I assume the WG had a good reason for preferring Informational.

Some editorial issues remain. From the review by Elwyn Davies:

...a brief section summarizing what DNSSEC needs and how it works would make it useful for operators trying to get a feel for the operational load before diving into the details. Otherwise there are a number of editorial nits that ought to be fixed:...

The full review with those nits will be posted at
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-dnsop-dnssec-operational-practices-07-davies.txt

PROTO Write-up

a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?

Yes.

b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The draft has been reviewed by many members of the community, including
operators and crypto experts. It was last called in the WG twice. The
earlier WGLC lead to a long list of open issues which were dealt with in
detail on the WG mailing list.
The chairs do not have any concerns about either depth or breadth of the
review.

c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

The chairs believe that the review has been extensive and the authors have
been very responsive to comments and suggestions. The fact that there is
currently not much real operational experience is reflected by requesting
publication as Informational rather than as BCP.

d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of?

The chairs do not see any such issues.

e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The consensus is very strong. The discussion on the mailing list had
many independent contributors and there were no contentious issues.

f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

g) Have the chairs verified that the document adheres to all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

h) Is the document split into normative and informative references?
Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?

All normative references are RFCs. Reference [10] is now RFC 4310
and reference [13] points into the IETF meeting proceedings. Both will
be adjusted in cooperation with the RFC Editor.