Skip to main content

Last Call Review of draft-ietf-dnsext-dnssec-alg-allocation-

Request Review of draft-ietf-dnsext-dnssec-alg-allocation
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-03-09
Requested 2010-02-24
Authors Paul E. Hoffman
I-D last updated 2010-03-03
Completed reviews Secdir Last Call review of -?? by Barry Leiba
Assignment Reviewer Barry Leiba
State Completed
Review review-ietf-dnsext-dnssec-alg-allocation-secdir-lc-leiba-2010-03-03
Completed 2010-03-03
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 document relaxes the requirement for registration of a crypto
algorithm for DNSSEC, allowing algorithms documented in informational
RFCs (including individual and independent submissions) to be
registered.  Until now, an algorithm had to be on standards track for

I have mixed feelings about this.  Since I haven't participated in any
conversations about this until now, please forgive me if I'm repeating
things that have (undoubtedly) been discussed already, and take this
with the appropriate condiments.

I understand the reasoning for allowing non-standards-track
algorithms, but I don't understand the reason not to use "Expert
Review", specifying that the documentation required is an RFC, and
giving at least *some* criteria for the expert to consider.
Otherwise, I wonder whether registration of poorly designed algorithms
will happen, and those algorithms may present an attractive nuisance,
getting widely implemented by virtue of being registered, despite what
this document says about that.  Given that this registry is part of
the basis for the security of DNS, I'd rather see at least some
oversight (noting that "oversee" and "overlook" mean very different

Even with expert review, we could allow weak or otherwise poor
algorithms to be registered, if we want to do that, with the addition
of a field in the registry that indicates the expert's assessment:
perhaps it could say "not recommended" as a sufficient warning.  That
would also allow updates later, giving erstwhile-good algorithms a
status of "compromised", "deprecated", or the like (and would be a
better place to note the deprecation of RSA/MD5 than in the algorithm
description, where it is now).

Going to the bullet at the bottom of page 2, what I'd like to ensure
is that an algorithm that "might not have been evaluated thoroughly
enough to be able to be put on the Standards Track" has nonetheless
been evaluated thoroughly enough to be in an "official list" of likely
candidates for implementation.  An "assessment" column would provide

I'd like to see the text of the last paragraph of section 3 change:
It should be noted that the order of algorithms in the IANA registry
does not signify or imply cryptographic strength or preference.
It should be noted that the presence of or order of algorithms in the
IANA registry does not signify or imply cryptographic strength or

I think this should have an informative reference to RFC 5226 section
4.1, which defines the IANA registration policies (and gives the
specific meaning of "RFC Required").

Barry Leiba  (barryleiba at