Re: draft-ietf-dnsext-dnssec-gost

Martin Rex <> Tue, 16 February 2010 15:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6912D3A7D05 for <>; Tue, 16 Feb 2010 07:02:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.216
X-Spam-Status: No, score=-10.216 tagged_above=-999 required=5 tests=[AWL=0.033, 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 9tAkImqyDifI for <>; Tue, 16 Feb 2010 07:02:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1F6353A7698 for <>; Tue, 16 Feb 2010 07:01:59 -0800 (PST)
Received: from by (26) with ESMTP id o1GF3Xqv014317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 16:03:33 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
Subject: Re: draft-ietf-dnsext-dnssec-gost
Date: Tue, 16 Feb 2010 16:03:32 +0100
In-Reply-To: <> from "Andrew Sullivan" at Feb 16, 10 08:53:53 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
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: Tue, 16 Feb 2010 15:02:01 -0000

Andrew Sullivan wrote:
> On Tue, Feb 16, 2010 at 01:18:48PM +0300, Basil Dolmatov wrote:
> >
> > Martin Rex пишет:
> > 
> >> I am somewhat illiterate to crypto math, so I'm wondering whether
> >> it is technicall possible to use a GOST R34.10-1994 key agreement
> >> (ephemeral keys) in conjunction with GOST R34.10-2001 certs&signatures,
> > Never ever interested. ;)
> To address Martin Rex's point, however, we would not need to know
> whether the draft's editors were ever interested, but whether it is
> technically possible.  This seems like a good (and so far unanswered)
> question.

I'm sorry for the confusion and off-topic that I created in the discussion.

The dnssec-gost document appears to be OK in being very explicit and
constrained in its usage of GOST, requiring the GOST R34.10-2001
signature algorithm and implying a single parameter set (A) for
the signatures.

The deprecated GOST R34.10-1994 algorithm is a non-issue for dnssec-gost.
Ensuring that no reference to GOST signatures is without R34.10-2001
qualifier in the document should be sufficient to prevent any potential

The use of GOST R34.11 for the hash algorithm should probably also be
changed to include the year GOST R34.11 to prevent confusion with
any future hash algorithms in the GOST R34.11 series.

Mandating a particular parameter set for an ECC crypto algorithm
is perfectly OK for interop.  Whether or not to include
a parameter set identifier in the DNS KEY RR is up to the DNSext
working group (Implementations of GOST are likely to know
all three GOST R34.10-2001 parameter sets listed in rfc-4357).

The byte order of GOST-related values seems to be confusing:

   Quoting RFC 4490:

   "The signature algorithm GOST R 34.10-2001 generates a digital
   signature in the form of two 256-bit numbers, r and s.  Its octet
   string representation consists of 64 octets, where the first 32
   octets contain the big-endian representation of s and the second 32
   octets contain the big-endian representation of r."

   4. DS Resource Records

   GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
   type {TBA2}.The wire format of a digest value is compatible with
   RFC4490 [RFC4490], that is digest is in little-endian representation.

Since there are already RFCs out there using GOST (CMS) and there
are implementations based on drafts (TLS) and maybe some under
evaluation (XMLsec) it seems a little late to ask for "pure"
ordering at this point in time.  Re-using the format/ordering
that is used in existing documents/protocols and implementations
appear to be OK to _me_.  IETF protocols provide more flexibility
at this point than e.g. ASN.1.  To me, it looks like there is
a little mess in GOST byte ordering in various usage scenarios,
so _I_ would not expect interop without interop testing, no matter
what ordering DNSsec defines. :-/

I really appreciate the mentioning of key and hash sizes in the
dnssec-gost document in section 5, because one can not easily
"look it up" in rfc-4357.  (It's in there, but not easy to determine).