Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05

David McGrew <mcgrew@cisco.com> Fri, 08 January 2010 21:10 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659D43A687C for <secdir@core3.amsl.com>; Fri, 8 Jan 2010 13:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 au48YUPWRvO9 for <secdir@core3.amsl.com>; Fri, 8 Jan 2010 13:10:17 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 64B1D3A686B for <secdir@ietf.org>; Fri, 8 Jan 2010 13:10:17 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEALstR0urR7H+/2dsb2JhbADBPpQKgjmBdgQ
X-IronPort-AV: E=Sophos;i="4.49,244,1262563200"; d="scan'208";a="463875566"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 08 Jan 2010 21:10:15 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o08LAFbK011166 for <secdir@ietf.org>; Fri, 8 Jan 2010 21:10:15 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 13:10:15 -0800
Received: from [10.32.254.210] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 13:10:15 -0800
Message-Id: <566303C7-A4F9-48B2-93E4-3F16FA394430@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: secdir@ietf.org
In-Reply-To: <20100108113528.gbmbl95nok8gsgwc@webmail.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
X-Priority: 3 (Normal)
Date: Fri, 8 Jan 2010 13:10:14 -0800
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <p06240812c76d0821dd1b@[10.20.30.158]> <20100108113528.gbmbl95nok8gsgwc@webmail.mit.edu>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 08 Jan 2010 21:10:15.0431 (UTC) FILETIME=[F9421970:01CA90A6]
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 21:10:18 -0000

I also agree with the compelling reasons that Steve and Paul have  
articulated.

I'm confused about one point, though.  The IANA considerations section  
in draft-ietf-dnsext-dnssec-gost-06 asks for GOST R 34.10-2001 and  
GOST R 34.11-94 to be registered as OPTIONAL.  Was there some  
suggestion to make them mandatory?

David

On Jan 8, 2010, at 8:35 AM, Uri Blumenthal wrote:

> I am in full agreement with the arguments Paul and Steve have made.
>
> Keep GOST as MAY.
>
> Quoting Paul Hoffman <phoffman@imc.org>rg>:
>> To take it one step further: a signing algorithm that is easily  
>> broken opens up a new attack vector. Imagine that all DNSSEC  
>> "client" implementations (resolvers) need to support two  
>> algorithms, A and B. If A and B are of actual equal strength, an  
>> attacker has an equal problem. However, if B is found to have  
>> weaknesses that allows an attacker to forge signatures, that  
>> attacker then can create a bogus chain to a trust anchor using B in  
>> the entire path.
>>
>> It is for this reason that DNSSEC does not, for example, require  
>> that resolvers MUST be able to validate RSA signatures with 256-bit  
>> keys. However, by saying that resolvers MUST be able to validate  
>> anything other than the widely-agreed-to algorithms, you are  
>> opening up such an attack.
>>
>> GOST signatures use a hash algorithm that has a known academic  
>> attack. Thus, even if the GOST asymmetric encryption algorithm is  
>> as strong as RSA with the size of keys that people are using, the  
>> overall signing algorithm may be weaker. This is *not* an argument  
>> that Russia should not use GOST: they have made their own security  
>> decisions based on the same knowledge that we have (and possibly  
>> more). It is, however, an argument against making everyone else be  
>> able to verify GOST signatures as if they were equivalent to other  
>> mandatory-to-implement signature algorithms.
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>>
>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir