Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt

Dmitry Burkov <dburk@burkov.aha.ru> Wed, 05 January 2011 22:43 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2544F3A6D02; Wed, 5 Jan 2011 14:43:02 -0800 (PST)
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36C53A6D02 for <dnsext@core3.amsl.com>; Wed, 5 Jan 2011 14:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.823
X-Spam-Level:
X-Spam-Status: No, score=0.823 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HELO_IS_SMALL6=0.556, HOST_EQ_RU=0.875, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+vaeC5FrKGz for <dnsext@core3.amsl.com>; Wed, 5 Jan 2011 14:43:00 -0800 (PST)
Received: from aha.ru (backend13.aha.ru [62.113.86.202]) by core3.amsl.com (Postfix) with ESMTP id 669363A6CD9 for <dnsext@ietf.org>; Wed, 5 Jan 2011 14:42:59 -0800 (PST)
Received: from [92.36.68.246] (account dburk@burkov.aha.ru HELO [192.168.0.128]) by backend13.aha.ru (CommuniGate Pro SMTP 4.3.11) with ESMTPSA id 67719770; Thu, 06 Jan 2011 01:45:04 +0300
References: <4D014A84.5070204@ogud.com> <4D2390DE.8050409@ogud.com> <4D23A061.3060501@vpnc.org> <4D248950.3040208@ogud.com> <4D248A72.5010404@vpnc.org> <a06240801c94a3ed54f9e@[10.31.200.116]> <4D24ADA3.20305@vpnc.org> <4D24BDF9.4020406@cryptocom.ru> <4D24BFF6.7060704@vpnc.org>
In-Reply-To: <4D24BFF6.7060704@vpnc.org>
Mime-Version: 1.0 (iPad Mail 8C148)
Message-Id: <827829D4-F559-4511-895F-AC2E402A5E54@burkov.aha.ru>
X-Mailer: iPad Mail (8C148)
From: Dmitry Burkov <dburk@burkov.aha.ru>
Date: Thu, 06 Jan 2011 01:48:18 +0300
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: "dnsext@ietf.org" <dnsext@ietf.org>
Subject: Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Strange discussion for me - if it can be named a discussion :-)
gost belongs to national recommendations with all their typical faults and mistakes
yes, if it was openly described and implemenented in open source - i can't understand what's the issue?
you can use it or not - it's your choice
the choice for russian authourity to issue new recommendations which can be more strength then some alternatives :-) - it is not a problem - i hope - if someone don't like competitors - it doesn't mean that they are dead 

Or I am wrong and someone is not satisfied that russian authorities simply didn't provided newest algorithms in open source? 





Sent from my iPad

On 05.01.2011, at 22:01, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> On 1/5/11 10:52 AM, Basil Dolmatov wrote:
>> I did not make any GOST references, moreover I did not imply any GOST
>> peculiarities in my comment, it is true for _any_ algorithm (the fact
>> that GOST belongs to "space of open standards" too is worth mentioning,
>> but irrelevant).
> 
> GOST limits which hash algorithm can be used in signatures to one choice, so that is indeed relevant.
> 
>> In any space of cryptographic standards the strength of algorithm is
>> measured not by "bits of strength" or "bits of key or hash length" but
>> by the number of operations which should be performed for given attack.
>> If one bothers to compare the algorithm strength more accurately then
>> the product of (operations)*(memory required) is used.
> 
> Both are used as measurements, and the one that is most commonly used in discussion is equivalent bit strength.
> 
>> Other figures have mostly marketing meaning rather than technical one.
> 
> That was not the IETF consensus when we adopted RFC 3766, which was heavily reviewed in the IETF's cryptographic community.
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext