Re: [secdir] Review of draft-ietf-dnsext-dnssec-gost-05

Samuel Weiler <weiler@watson.org> Thu, 14 January 2010 23:43 UTC

Return-Path: <weiler@watson.org>
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 CE6483A6856 for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 15:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.799
X-Spam-Level:
X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599]
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 ndHuQu9vRZI9 for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 15:43:26 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id DD88A3A67AA for <secdir@ietf.org>; Thu, 14 Jan 2010 15:43:25 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o0ENhKj9096138; Thu, 14 Jan 2010 18:43:20 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o0ENhKkF096135; Thu, 14 Jan 2010 18:43:20 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 14 Jan 2010 18:43:20 -0500 (EST)
From: Samuel Weiler <weiler@watson.org>
To: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com>
Message-ID: <alpine.BSF.2.00.1001141826160.70709@fledge.watson.org>
References: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 14 Jan 2010 18:43:21 -0500 (EST)
Cc: draft-ietf-dnsext-dnssec-gost@tools.ietf.org, dnsext-chairs@tools.ietf.org, secdir <secdir@ietf.org>
Subject: Re: [secdir] Review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
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: Thu, 14 Jan 2010 23:43:26 -0000

On Thu, 14 Jan 2010, Richard L. Barnes wrote:

> Section 5:
> This section seems unnecessary, since GOST has only one size for keys, 
> signatures, and digests.

>From the perspective of the DNS world, I think being explicit about 
this is actually pretty handy.  I see benefit in leaving it.

Other than that, I generally concur with the secdir reviews received 
to date, particuarly the lowering of the requirement level.


Also, while I haven't thoroughly reviewed this draft since April 2009 
(when the DNSEXT WG was asking whether to adopt it or not), a couple 
of things jump out, which I'll share now rather than wait for the IETF 
last call:

Section 6.2, on NSEC3 support, is a little vague.  I think the doc 
means "zones signed with the algorithms specified in this document may 
use either NSEC or NSEC3 and validators supporting this algorithm must 
support both NSEC and NSEC3".  I'm not sure my wording is much 
clearer, but a change is needed.

In the IANA considerations, do not use the asterisk.  Just say that 
this algorithm suite isn't being defined for transaction security 
mechanisms.

Also, the IANA considerations section includes the requirement status 
column, which implicitly assumes that we are advancing 
draft-ietf-dnsext-dnssec-registry-fixes-01.  I'm not convinced that's 
going to happen any time soon, particularly given the lackluster 
response to draft-ogud-iana-protocol-maintenance-words, which it 
depends on.  So... that needs to be tracked.  It's not necessary to 
cite registry-fixes, but it probably is necessary to treat it as a 
dependency for publication purposes.

-- Sam