Re: draft-ietf-dnsext-dnssec-gost

Martin Rex <> Thu, 11 February 2010 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6F9B3A726B for <>; Thu, 11 Feb 2010 14:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.217
X-Spam-Status: No, score=-10.217 tagged_above=-999 required=5 tests=[AWL=0.032, 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 Jz7R650mF0zx for <>; Thu, 11 Feb 2010 14:42:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 91DEB3A682A for <>; Thu, 11 Feb 2010 14:42:49 -0800 (PST)
Received: from by (26) with ESMTP id o1BMhwE7003424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 23:43:58 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
Subject: Re: draft-ietf-dnsext-dnssec-gost
Date: Thu, 11 Feb 2010 23:43:57 +0100
In-Reply-To: <p06240806c799d87e7406@[]> from "Stephen Kent" at Feb 11, 10 12:57:26 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
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: Thu, 11 Feb 2010 22:42:50 -0000

Stephen Kent wrote:
> I recommend that the document not be approved by the IESG in its 
> current form.  Section 6.1 states:
> >6.1.  Support for GOST signatures
> >
> >    DNSSEC aware implementations SHOULD be able to support RRSIG and
> >    DNSKEY resource records created with the GOST algorithms as
> >    defined in this document.
> There has been considerable discussion on the security area 
> directorate list about this aspect of the document. All of the SECDIR 
> members who participated in the discussion argued that the text in 
> 6.1 needs to be changed to MAY from SHOULD. The general principle 
> cited in the discussion has been that "national" crypto algorithms 
> like GOST ought not be cited as MUST or SHOULD in standards like 
> DNESEC. I refer interested individuals to the SECDIR archive for 
> details of the discussion.

I agree with Stephen Kent.  That needs to be a MAY.

GOST is IMHO _not_ mature enough and not sufficiently understood and
availble to justify a SHOULD or RECOMMENDED for its support/use
in a core internet protocol.

Over the past year we had our SSL/TLS supplier add support for GOST
TLS ciphersuites to add OEM SSL/TLS implementation (in form of a
third-party crypto plugin that can be certified by the relevant
russian authorities).

One of the problems with GOST is its lack of availability of
documentation/specification and the meaning, purpose and
characteristics of algorithm parameters.

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.  There are IETF documents listing
specific algorithm Identifier parameters (sets), referenced by OIDs,
and those OIDs are issued by one particular company.  I haven't
seen any documentation about the characteristics, purpose of
these algorithm parameters sets and the means/process to define
other parameter (sets).