Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-02

[Andrew Sullivan <[e-mail]>]

Hi,

Thanks for the review of this document.

On Tue, Mar 02, 2010 at 02:43:07PM -0500, Barry Leiba wrote:

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

I have a certain amount of sympathy for this comment, but the plain
fact is that the DNS community does not actually have the expertise to
evaluate cryptographic algorithms anyway. 

The upshot therefore of your suggestion is that the expert review
required in this area would probably require an expert panel in each
case, with one member from the DNS community and another from the
security community.  

More importantly, I'm not sure there's actually a problem to solve
here.  Do we have a problem in other protocols where poor crypto
algorithms have won out over better-designed algorithms?

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

We do in fact have a completely separate effort underway to update the
registry in order to allow certain kinds of indicators like this.  The
WG seemed to agree that these were separate problems and didn't want
to conflate them.  Does that other effort address your concern?

> 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 see no objection to that alteration.

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

I have no objection to this reference.

Thanks again for the review,

Andrew (doc shepherd)



-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.