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

Barry Leiba <barryleiba@computer.org> Tue, 02 March 2010 19:43 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7305C3A8AF6; Tue, 2 Mar 2010 11:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TijhO+m0elLA; Tue, 2 Mar 2010 11:43:11 -0800 (PST)
Received: from mail-pz0-f171.google.com (mail-pz0-f171.google.com [209.85.222.171]) by core3.amsl.com (Postfix) with ESMTP id 4678D3A8AEA; Tue, 2 Mar 2010 11:43:11 -0800 (PST)
Received: by pzk1 with SMTP id 1so525342pzk.17 for <multiple recipients>; Tue, 02 Mar 2010 11:43:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tIpl7oHLKxs/DZmqBsuFGpfgzczp3zQePdcVgfDs2Us=; b=DlZR14+yVXZ+ViU36al1LAx5Gcy9kI92rdf43MU9Bv2IMYHjgm+CqSLRwAM58/ST76 tDnrn9c5hv6pLzuz/wn9wuojH7Y5YpA0w2ckBTf3Rux0x0K9ctnrR9ngrSLBtNpuJ0Gm lt3fTIobTv/6SXGMDp61igPMwfa8GO0bO8U0A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=bT18woPzJyY0Dp7V5WzGB3+9MEkDbMZWFvVjSv1Kc1dlP+nfdoz881GnSGhQdnl8Pb iQ/iI34skR4wuH4YBsGdAY0c8DajNQO6G4BbBGwIvRInfwFR5xFCcsNwH0lq+7tB2/56 8OS17atuM62++PSE6AKstrOF5CF89g6ZTT4mQ=
MIME-Version: 1.0
Sender: barryleiba@gmail.com
Received: by 10.142.249.25 with SMTP id w25mr3760894wfh.15.1267558987819; Tue, 02 Mar 2010 11:43:07 -0800 (PST)
Date: Tue, 2 Mar 2010 14:43:07 -0500
X-Google-Sender-Auth: 2edecadf990bae95
Message-ID: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: secdir@ietf.org, draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: iesg@ietf.org
Subject: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2010 19:43:12 -0000

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@computer.org)
http://internetmessagingtechnology.org/