Re: draft-ietf-dnsext-dnssec-gost

Martin Rex <> Fri, 12 February 2010 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25CCF3A719C for <>; Fri, 12 Feb 2010 08:11:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.219
X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sOgGFAYdNJHN for <>; Fri, 12 Feb 2010 08:11:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 55F4C28C16A for <>; Fri, 12 Feb 2010 08:11:50 -0800 (PST)
Received: from by (26) with ESMTP id o1CGD56K022851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Feb 2010 17:13:05 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
Subject: Re: draft-ietf-dnsext-dnssec-gost
Date: Fri, 12 Feb 2010 17:13:04 +0100
In-Reply-To: <> from "Basil Dolmatov" at Feb 12, 10 03:00:35 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
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: Fri, 12 Feb 2010 16:11:59 -0000

Basil Dolmatov wrote:
> Martin Rex пишет:
> > Admittedly, I know very little about the cryptographic
> > details, but there are two GOST signature algorithms
> > (GOST R34.10-1994 and GOST R34.10-2001). The earlier
> > appears to bear some similarity with DH, the newer appears to bear
> > similarity with ECDH.  
> > Whether and how much the -1994 version is
> > deprecated is also a complete mystery.  
> It is written in the text of GOST -2001
> >  2. GOST R 34.10-2001 was accepted and activated by the Act 380-st of
>     12.09.2001 issued by the Russian federal committee for standards.
>     ...
>     4. GOST R 34.10-2001 replaces GOST R 34.10-94.
> So, GOST -1994 for digital signature _is_ deprecated and replaced from 
> 12.09.2001.
> The transition period is not stated explicitly because it is obvious 
> from standard procedure of certification in Russia.
> No certificate can be issued for any hardware/software using -1994 
> algorithm after 12.09.2001 and the certification period is 3 years.
> So, after 12.09.2004 there can be no operating hardware/software using 
> -1994 algorithm.
> Just that simple. ;)

I'm still quite confused.

All references to GOST signature algorithms of the kind [GOST3410] 
ought to be fixed to say [GOST3410-2001].

It seems it mixed up the (deprecated) signature Algorithm GOST R34.10-1994
and the hash/digest algorith GOST R34.11-1994 that is still being used
for signatures with GOST R34.10-2001.

RFC-4357 was published in January 2006, i.e. after GOST signature
algorithm R34.10-1994 algorithm was deprecated (12.09.2001) and
after which is must no longer be used (12.09.2004) according to
your description.  The GOST TLS ciphersuite document still defines
and uses the deprecated signature algorithm...

IMHO, rfc4357 should have been completely stripped from GOST R34.10-1994
before publication if what you describes really applies to this algorithm.

Unfortunately, rfc-4357 does _not_even_mention_ that GOST R34.10-1994
is deprecated and must no longer be used, and is at the same time
abiguous about the name of the Hash algorithm.  The table of
contents and section heading call it only GOSTR3411.

Regarding key size confusion of the old signature algorithm
in rfc-4357:

GOST R34.10-94:
 non given    RFC-4357  5.1. VKO GOST R 34.10-94
 512 or 1024  RFC-4357  8.3. GOST R 34.10-94 Public Key Algorithm Parameters

GOST R34.10-2001:
 512          RFC-4357  5.2. VKO GOST R 34.10-2001
 none given   RFC-4357  8.4. GOST R 34.10-2001 Public Key Algorithm Parameters

RFC-4357 Security Considerations says the following about the
parameters sets (for signature and the hash algorithm):

   Use of the test parameter sets or parameter sets not described herein
   is NOT RECOMMENDED.  When different parameters are used, it is
   RECOMMENDED that they be subjected to examination by an authorized
   agency with approved methods of cryptographic analysis.

Which is not really helpful.  Any specification referencing rfc-4357
will now have to declare which kind of parameter sets (as defined in
rfc-4357) should be used/accepted for which purpose and which
parameter set is the default.

The purpose, existance and semantics of the "test" algorithm parameter
sets are particularly confusing.