Re: draft-ietf-dnsext-dnssec-gost

Basil Dolmatov <dol@cryptocom.ru> Sat, 13 February 2010 17:28 UTC

Return-Path: <dol@cryptocom.ru>
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 D0BF33A7708 for <ietf@core3.amsl.com>; Sat, 13 Feb 2010 09:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.219
X-Spam-Level:
X-Spam-Status: No, score=0.219 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875]
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 IBEwb4GUKw+k for <ietf@core3.amsl.com>; Sat, 13 Feb 2010 09:28:45 -0800 (PST)
Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id B59413A73C8 for <ietf@ietf.org>; Sat, 13 Feb 2010 09:28:44 -0800 (PST)
Received: from [192.168.63.201] (ppp91-78-16-121.pppoe.mtu-net.ru [91.78.16.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 2287B465D9; Sat, 13 Feb 2010 20:30:07 +0300 (MSK)
Message-ID: <4B76E19E.8040103@cryptocom.ru>
Date: Sat, 13 Feb 2010 20:30:06 +0300
From: Basil Dolmatov <dol@cryptocom.ru>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: mrex@sap.com
Subject: Re: draft-ietf-dnsext-dnssec-gost
References: <201002121613.o1CGD4uU004272@fs4113.wdf.sap.corp>
In-Reply-To: <201002121613.o1CGD4uU004272@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: ietf@ietf.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: Sat, 13 Feb 2010 17:28:45 -0000

Martin Rex пишет:
>
> I'm still quite confused.
>
> All references to GOST signature algorithms of the kind [GOST3410] ought to be fixed to say [GOST3410-2001].
>   
I think that can de done, despite the fact that there is no other 
algorithm coded as GOST 3410, except GOST 34.10-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.
>
>   
It seems that no mixture takes place. Signature standard has number 
34.10, hash standard has number 34.11.
I cannot see how they can be mixed up.

> 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.
>   
I think that is a question to authors of RFC4357 and I think that 
corrections should be issued.

>
> 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.
>   
Yes. And this is done in the draft text. Read it.

>  Corresponding public key parameters are those identified by
>    id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357 <http://tools.ietf.org/html/rfc4357>],
>    and the digest parameters are those identified by
>    id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357 <http://tools.ietf.org/html/rfc4357>].
>   
No confusions, no ambiguity.
> The purpose, existance and semantics of the "test" algorithm parameter
> sets are particularly confusing.
>   

Document -
> draft-ietf-dnsext-dnssec-gost-06
does not use any "test" parameters from RFC 4357 and does not reference 
any of them.


HTH,

dol@