Re: draft-ietf-dnsext-dnssec-gost

Ran Atkinson <> Mon, 15 February 2010 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73A7D3A7AD3 for <>; Mon, 15 Feb 2010 07:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cOyqKmK3dvSQ for <>; Mon, 15 Feb 2010 07:45:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4E7C73A79B5 for <>; Mon, 15 Feb 2010 07:45:23 -0800 (PST)
Received: by with SMTP id 19so63790fgg.13 for <>; Mon, 15 Feb 2010 07:46:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=ITO3hbSQ2vkXJV2KqhBdfURRha9xSLy1hExis8W66us=; b=YWg5PVT7jhYfXcmb/nvSYcLFcyTqSUBbWVmJB2/mqgQCBtV8Oy3pNw4nAWW1PB8xCm 94pysDKyHQB6LF/lghopIqjMbAl1lqEyBwu+PxgnbM+t/+s6lLH4ArH7705WPZR1hBnG cheep+HGbAMBEczOxvo5kAxitrLz3cMbetCUk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=LoQU8skaJak6b1z07+CLd0R3DlfBf+FVAT9q1mte4oBVe3MuAypq0R1VXNtCb98jn1 2wwqs0Z/EkIaQECFmPA561UMg1PpcyT4Ilt3sDJUjI/MzgKSuUffpFSjRP52NLsCPkzY pAiYHqaEK4F/fZSewQJ532oSHVVCKDvgyVQME=
Received: by with SMTP id y36mr9262718fgi.17.1266248810695; Mon, 15 Feb 2010 07:46:50 -0800 (PST)
Received: from ( []) by with ESMTPS id 14sm3073412fxm.15.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Feb 2010 07:46:50 -0800 (PST)
From: Ran Atkinson <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: draft-ietf-dnsext-dnssec-gost
Date: Mon, 15 Feb 2010 10:46:47 -0500
Message-Id: <>
Mime-Version: 1.0 (Apple Message framework v1077)
X-Mailer: Apple Mail (2.1077)
X-Mailman-Approved-At: Tue, 16 Feb 2010 08:09:52 -0800
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: Mon, 15 Feb 2010 15:45:24 -0000


hHere are at least 2 issues under discussion within this thread.
I'd like to address them separately, but in the same note.

(1) Quality of GOST specification

While I'm very happy to see any algorithm publicly documented
in an I-D or RFC, I agree with Martin Rex that the current
RFC-4357 on GOST 3410-2001 is not sufficiently clear and 
complete to easily lead to entirely-independent interoperable 
implementations.  It ought to be possible for a non-Russian,
non-certified, implementation to interoperate with any other
implementation of the same algorithm -- from an implementer 
reading the RFC alone.

Martin Rex's notes to the IETF list:

I share Martin Rex's desire for some clarifications to that
fundamental document, and I also share his concern that the 
RFC specifying GOST does not specify what an implementation 
ought to do when it encounters "signatures with other parameter 
sets".  Such a revision ought to make more clear, perhaps
in "Security Considerations" as Martin Rex earlier suggested,
that GOST-3410-2001 is entirely separate from GOST 3410-94.
That fact is NOT obvious from reading RFC-4357 and is quite
relevant to implementers (of either version) of GOST 3410.
In that revision to RFC-4357, I'd love to see an Appendix with 
some test vectors for GOST, as well.  Documenting a wide range
of suitable test vectors can be extremely helpful in verifying 
that a particular implementation of some algorithm is operating 
correctly, which in turn is fundamental to protocol interoperability.  
(RFC-4231 provides an example of test vectors for some other 
openly specified algorithms.)

(2) DNSsec use of GOST specification

For the several reasons various folks have already expressed 
on the IETF list, and also for the reasons above in (1), 
I share the view that GOST should be "MAY" rather than "SHOULD" 
for use in DNS Security.


R. Atkinson