Stephen Kent <kent@bbn.com> Thu, 11 February 2010 17:56 UTC

Return-Path: <kent@bbn.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 7F42628C1D1 for <ietf@core3.amsl.com>; Thu, 11 Feb 2010 09:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id j4IWKBwdemKV for <ietf@core3.amsl.com>; Thu, 11 Feb 2010 09:56:14 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com []) by core3.amsl.com (Postfix) with ESMTP id B262828C124 for <ietf@ietf.org>; Thu, 11 Feb 2010 09:56:14 -0800 (PST)
Received: from dhcp89-089-170.bbn.com ([]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1NfdI9-000O6y-3e; Thu, 11 Feb 2010 12:57:29 -0500
Mime-Version: 1.0
Message-Id: <p06240806c799d87e7406@[]>
Date: Thu, 11 Feb 2010 12:57:26 -0500
To: ietf@ietf.org
From: Stephen Kent <kent@bbn.com>
Subject: draft-ietf-dnsext-dnssec-gost
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Feb 2010 17:56:15 -0000

I recommend that the document not be approved by the IESG in its 
current form.  Section 6.1 states:

>6.1.  Support for GOST signatures
>    DNSSEC aware implementations SHOULD be able to support RRSIG and
>    DNSKEY resource records created with the GOST algorithms as
>    defined in this document.

There has been considerable discussion on the security area 
directorate list about this aspect of the document. All of the SECDIR 
members who participated in the discussion argued that the text in 
6.1 needs to be changed to MAY from SHOULD. The general principle 
cited in the discussion has been that "national" crypto algorithms 
like GOST ought not be cited as MUST or SHOULD in standards like 
DNESEC. I refer interested individuals to the SECDIR archive for 
details of the discussion.