Re: draft-ietf-dnsext-dnssec-gost

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A438C28C240 for <>; Thu, 11 Feb 2010 13:58:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.944
X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JOPGegVtyG3l for <>; Thu, 11 Feb 2010 13:58:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B8E1728C23C for <>; Thu, 11 Feb 2010 13:58:47 -0800 (PST)
Received: from [] (helo=[]) by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1Nfh4r-000232-HD; Thu, 11 Feb 2010 17:00:01 -0500
Message-Id: <>
From: "Richard L. Barnes" <>
To: Paul Hoffman <>
In-Reply-To: <p06240804c79a234f3ad8@[]>
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@[]> <> <> <p06240804c79a234f3ad8@[]>
X-Mailer: Apple Mail (2.936)
Cc:, Olafur Gudmundsson <>,
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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