Re: draft-ietf-dnsext-dnssec-gost

Martin Rex <mrex@sap.com> Thu, 11 February 2010 22:42 UTC

Return-Path: <mrex@sap.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F9B3A726B for <ietf@core3.amsl.com>; Thu, 11 Feb 2010 14:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.217
X-Spam-Level:
X-Spam-Status: No, score=-10.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Jz7R650mF0zx for <ietf@core3.amsl.com>; Thu, 11 Feb 2010 14:42:49 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 91DEB3A682A for <ietf@ietf.org>; Thu, 11 Feb 2010 14:42:49 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o1BMhwE7003424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 23:43:58 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201002112243.o1BMhvn1003940@fs4113.wdf.sap.corp>
Subject: Re: draft-ietf-dnsext-dnssec-gost
To: kent@bbn.com
Date: Thu, 11 Feb 2010 23:43:57 +0100
In-Reply-To: <p06240806c799d87e7406@[128.89.89.170]> from "Stephen Kent" at Feb 11, 10 12:57:26 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Feb 2010 22:42:50 -0000

Stephen Kent wrote:
> 
> I recommend that the document not be approved by the IESG in its 
> current form.  Section 6.1 states:
> 
> >6.1.  Support for GOST signatures
> >
> >    DNSSEC aware implementations SHOULD be able to support RRSIG and
> >    DNSKEY resource records created with the GOST algorithms as
> >    defined in this document.
> 
> There has been considerable discussion on the security area 
> directorate list about this aspect of the document. All of the SECDIR 
> members who participated in the discussion argued that the text in 
> 6.1 needs to be changed to MAY from SHOULD. The general principle 
> cited in the discussion has been that "national" crypto algorithms 
> like GOST ought not be cited as MUST or SHOULD in standards like 
> DNESEC. I refer interested individuals to the SECDIR archive for 
> details of the discussion.

I agree with Stephen Kent.  That needs to be a MAY.

GOST is IMHO _not_ mature enough and not sufficiently understood and
availble to justify a SHOULD or RECOMMENDED for its support/use
in a core internet protocol.

Over the past year we had our SSL/TLS supplier add support for GOST
TLS ciphersuites to add OEM SSL/TLS implementation (in form of a
third-party crypto plugin that can be certified by the relevant
russian authorities).

One of the problems with GOST is its lack of availability of
documentation/specification and the meaning, purpose and
characteristics of algorithm parameters.

Admittedly, I know very little about the cryptographic
details, but there are two GOST signature algorithms
(GOST R34.10-1994 and GOST R34.10-2001). The earlier
appears to bear some similarity with DH, the newer appears to bear
similarity with ECDH.  Whether and how much the -1994 version is
deprecated is also a complete mystery.  There are IETF documents listing
specific algorithm Identifier parameters (sets), referenced by OIDs,
and those OIDs are issued by one particular company.  I haven't
seen any documentation about the characteristics, purpose of
these algorithm parameters sets and the means/process to define
other parameter (sets).


-Martin