Re: draft-ietf-dnsext-dnssec-gost

Andrew Sullivan <> Tue, 16 February 2010 13:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA7BB3A76B1 for <>; Tue, 16 Feb 2010 05:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.037
X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VNrOVXru369c for <>; Tue, 16 Feb 2010 05:52:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E43893A7508 for <>; Tue, 16 Feb 2010 05:52:21 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 85D7E1ECB402 for <>; Tue, 16 Feb 2010 13:53:55 +0000 (UTC)
Date: Tue, 16 Feb 2010 08:53:53 -0500
From: Andrew Sullivan <>
Subject: Re: draft-ietf-dnsext-dnssec-gost
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.18 (2008-05-17)
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 13:52:22 -0000

No hat.

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)

> The usage of GOST R 34.10-94 is fully prohibited starting 1 of January 2008.

Certainly, this prohibition is irrelevant.  We are not offering
technical interoperation documents _for a particular legal framework_,
but technical interoperation documents _for the Internet_.  The
documents must therefore assume that, if someone can come up with a
bad idea that is nevertheless consistent with the document in
question, someone will.  (If you doubt this, please examine the
Internet -- pretty much any part of it you like -- more carefully.)

So I think Martin's question is appropriate, and his suggestion
up-thread to be a good one.  The more specific the document can be
made, the better for all concerned.


Andrew Sullivan
Shinkuro, Inc.