Last Call Review of draft-ietf-dnsext-dnssec-algo-imp-status-
review-ietf-dnsext-dnssec-algo-imp-status-secdir-lc-kaufman-2012-07-13-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This is a short document intended to be BCP recommending algorithms to be
implemented in DNSSEC component software. It explicitly does not make
recommendations as to what algorithms should be configured in deployments, but
only concerns the algorithms supported in software (and presumably hardware).

While the document title (Applicability Statement: DNS Security (DNSSEC) DNSKEY
Algorithm Implementation Status) makes it appear that the document describes
implementations as they exist today, the main focus of the document is in
recommending the algorithms that should be deployed (appropriate to a BCP). It
divides algorithms into four categories: MUST IMPLEMENT, RECOMMENDED TO
IMPLEMENT, OPTIONAL, and MUST NOT IMPLEMENT. There is a single MUST IMPLEMENT
algorithm: RSASHA1, and a single MUST NOT IMPLEMENT algorithm: RSAMD5. Nine
other algorithms are divided between RECOMMENDED TO IMPLEMENT and OPTIONAL     
.

I found a number of aspects of the document troubling.

First, the document does not distinguish between algorithms that are
recommended for signing new DNS records vs. algorithms that are recommended for
verifying existing DNS records. It's possible that this document only intends
to speak to the former, but I could not find any indication of that. In order
to be able to advance to use of better algorithms, we need to deploy
verification software for those better algorithms long before we start signing
with them. I would think that any algorithm that is RECOMMENDED TO IMPLEMENT
for signing should be MUST IMPLEMENT for verification. Even RSAMD5 should be at
least RECOMMENDED TO IMPLEMENT for verifiers unless there are no such
signatures out there. An implementation that only supported the MUST IMPLEMENT
algorithm would not be able to verify signatures on the root zone.

Second, while the document is explicit about hash algorithms, if says nothing
about key sizes for the asymmetric algorithms. The world is ratcheting up RSA
key sizes, and signing with a 512 bit RSA key is as bad as signing with MD5. I
would think the spec should say something about minimum and maximum RSA, DSA,
and DH key sizes.

Finally, having RSASHA1 as the MUST IMPLEMENT algorithm should be
controversial. SHA1 is showing signs of weakness, and DNSSEC is subject to
collision attacks if the attacker is allowed to provide arbitrary data for
posting in some DNS record of a zone. It is possible that RSASHA1 needs to
remain the BCP signing algorithm for some time going forward because there are
a large number of deployed verifiers that support nothing better, but if that's
true the document should say so (possibly in Security Considerations). But that
is all the more reason to specify MUST IMPLEMENT for stronger algorithms in
verifiers.

Nits:

Section 2.1 first paragraph last sentence has bad sentence structure, making it
difficult to interpret.

Section 2.1 second paragraph: "percieved" -> "perceived"