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"