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

Olafur Gudmundsson <ogud@ogud.com> Fri, 15 January 2010 15:16 UTC

Return-Path: <ogud@ogud.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 453893A6A5D for <secdir@core3.amsl.com>; Fri, 15 Jan 2010 07:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.659
X-Spam-Level:
X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 eySh30KVxkMU for <secdir@core3.amsl.com>; Fri, 15 Jan 2010 07:16:17 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 3DAE33A6A33 for <secdir@ietf.org>; Fri, 15 Jan 2010 07:16:17 -0800 (PST)
Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0FFG8aO085884; Fri, 15 Jan 2010 10:16:08 -0500 (EST) (envelope-from ogud@ogud.com)
Message-Id: <201001151516.o0FFG8aO085884@stora.ogud.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 15 Jan 2010 10:16:04 -0500
To: secdir-secretary@mit.edu, "Richard L. Barnes" <rbarnes@bbn.com>
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <alpine.BSF.2.00.1001141826160.70709@fledge.watson.org>
References: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com> <alpine.BSF.2.00.1001141826160.70709@fledge.watson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20
X-Mailman-Approved-At: Fri, 15 Jan 2010 08:02:23 -0800
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
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: Fri, 15 Jan 2010 15:16:18 -0000

At 18:43 14/01/2010, Samuel Weiler wrote:
>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.

I agree the document should say one way or the other, not supporting
Transaction security is easier on all.


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

Good point, will talk to AD about this before the document
goes to the IESG after IETF LC ends.

         Olafur