Last Call Review of draft-ietf-dnsext-dnssec-alg-allocation-
review-ietf-dnsext-dnssec-alg-allocation-secdir-lc-leiba-2010-03-03-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 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
registration.

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
things).

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
that.

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

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
-- 
Barry Leiba  (barryleiba at computer.org)


http://internetmessagingtechnology.org/