Re: draft-ietf-dnsext-dnssec-gost

Olafur Gudmundsson <> Tue, 16 February 2010 00:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 607263A7BF3 for <>; Mon, 15 Feb 2010 16:42:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bIPddSTyqJMr for <>; Mon, 15 Feb 2010 16:42:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 365CD3A7A3C for <>; Mon, 15 Feb 2010 16:42:20 -0800 (PST)
Received: from [IPv6:::1] ( []) by (8.14.3/8.14.3) with ESMTP id o1G0hnP0096176 for <>; Mon, 15 Feb 2010 19:43:49 -0500 (EST) (envelope-from
Message-ID: <>
Date: Mon, 15 Feb 2010 19:43:50 -0500
From: Olafur Gudmundsson <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv: Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
Subject: Re: draft-ietf-dnsext-dnssec-gost
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on
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 00:42:21 -0000

On 15/02/2010 6:37 PM, Martin Rex wrote:
> Mark Andrews wrote:
>> In message<>, Martin Rex writes
>> :
>>> OK, I'm sorry.  For the DNSsec GOST signature I-D, the default/prefered (?)
>>> parameter sets are explicitly listed in last paragraph of section 2
>>> of draft-ietf-dnsext-dnssec-gost-06.  However, it does _NOT_ say what to
>>> do if GOST R34.10-2001 signatures with other parameter sets are encountered.
>> Since each end adds the parameters and they are NOT transmitted this
>> can never happen.  If one end was to change the parameters then nothing
>> would validate.
> OK.  I didn't know anything abouth DNSSEC when I entered the disussion...
> Having scanned some of the available document (rfc-4034,rfc-4035,rfc-2536
> and the expired I-D draft-ietf-dnsext-ecc-key-10.txt) I'm wondering
> about the following:
>    - the DNS security algorithm tag ought to be GOST R34.10-2001
>      and not just "GOST"

This is a good point, adding a version label is a possiblity in this
case or just in the future cases, but I think slapping one on
this is fine.

>    - DSA and the expired ECC draft spell out the entire algorithm
>      parameters in the key RRs, which preclues having to assign
>      additional algorithm identifiers if a necessity comes up to
>      use different algorithm parameters.
DSA did not cover the case if the key is > 1024 bit.
ECC draft was killed due to the fact it was impossible to guarantee that
a implementation supporting ECC would be able to handle all the
possible curves that the proposal allowed.

>      Wouldn't it be sensible to do the same for GOST R34.10-2001 keys --
>      i.e. list the parameter set as part of the public key data?
>      Given the procedure of the standardization body that defines GOST
>      the parameter set OID could be used in alternative to spelling
>      out each of the element in the parameter set in full.
>      Implying the paramter set A for the GOST R34.10-2001 algorithm does
>      not seem very "agile", given the limited number range for the algorithm
>      field in DNS security.
For interoperability reasons we WANT MINIMAL flexibility for 
implementors/users. Thus we stripped all that out and picked ONE
possible GOST/2001 curve.

> Given the differences between -1994 and -2001 versions,
> any successor GOST R34.10-201X standard may not be able to reuse
> the DNSKEY record anyway and need a new algorithm identifier.
> And at that point, an unqualified label "GOST" would become
> ambiguous.
see above,

	Olafur (document shepeard)