Re: draft-ietf-dnsext-dnssec-gost

"Richard L. Barnes" <rbarnes@bbn.com> Thu, 11 February 2010 21:58 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A438C28C240 for <ietf@core3.amsl.com>; Thu, 11 Feb 2010 13:58:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.944
X-Spam-Level:
X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.655, 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 JOPGegVtyG3l for <ietf@core3.amsl.com>; Thu, 11 Feb 2010 13:58:47 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B8E1728C23C for <ietf@ietf.org>; Thu, 11 Feb 2010 13:58:47 -0800 (PST)
Received: from [128.89.255.16] (helo=[172.27.15.203]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Nfh4r-000232-HD; Thu, 11 Feb 2010 17:00:01 -0500
Message-Id: <22C788D0-D0AD-40EB-ADE8-33C738BFA267@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <p06240804c79a234f3ad8@[75.101.18.87]>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: draft-ietf-dnsext-dnssec-gost
Date: Thu, 11 Feb 2010 17:00:00 -0500
References: <p06240806c799d87e7406@[128.89.89.170]> <4B74646F.3080904@ogud.com> <20100211210434.GJ9592@shinkuro.com> <p06240804c79a234f3ad8@[75.101.18.87]>
X-Mailer: Apple Mail (2.936)
Cc: ietf@ietf.org, Olafur Gudmundsson <ogud@ogud.com>, iesg@iesg.org
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 21:58:48 -0000

I agree with Steve's and Paul's analyses.

In addition, it's not clear to me how this SHOULD-level requirement  
squares with the IANA registration of this algorithm as OPTIONAL (in  
Section 8), since in RFC 2119 OPTIONAL == MAY.  The document that  
defines that registry (draft-ietf-dnsext-dnssec-registry-fixes) does  
not allow algorithms to be RECOMMENDED, so it seems like the  
requirement for support has to be either a MUST or a MAY to be  
consistent with the registry.

--Richard



On Feb 11, 2010, at 4:24 PM, Paul Hoffman wrote:

> At 4:04 PM -0500 2/11/10, Andrew Sullivan wrote:
>> So the question here is not what algorithms get "first class" status
>> in general, but whether we want to have different classes of support
>> for DNSSEC, given the current conditions.
>
> First off, thank you for better stating the question.
>
> There are a plethora of signing algorithms. Note that a signing  
> algorithm consists of a public key algorithm *and* a hash algorithm.
>
> The question here is whether they also have SHOULD-level  
> requirements to process every signing algorithm that is in the IANA  
> registry. Having such a requirement gives attackers a much wider  
> target: in order to spoof a signature, they can pick the weakest of  
> a large collection of algorithms.
>
> For example, there is already a published attack on the GOST hash  
> function that does not exist in SHA-256 and SHA-512. The GOST  
> algorithms have had much less cryptographic review than other  
> algorithms. If that attack becomes practical, an attacker can create  
> signatures using GOST that he/she could not create in RSA/SHA-256 or  
> RSA/SHA-512.
>
> Given this, the answer to the question should be "no, not all  
> algorithms automatically get SHOULD-level requirements". The IETF  
> can, on a case-by-case basis, decide if they want to update the base  
> DNSSEC spec to include a SHOULD-level or MUST-level requirement for  
> a new signature algorithm.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf