[secdir] Review of draft-ietf-dnsext-dnssec-gost-05

"Richard L. Barnes" <rbarnes@bbn.com> Thu, 14 January 2010 23:06 UTC

Return-Path: <rbarnes@bbn.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 A2FB03A6908 for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 15:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 FDBL17RnkCdo for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 15:06:13 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9B00D3A6890 for <secdir@ietf.org>; Thu, 14 Jan 2010 15:06:13 -0800 (PST)
Received: from [128.89.253.32] (helo=[192.168.1.45]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1NVYlV-000O32-CO; Thu, 14 Jan 2010 18:06:10 -0500
Message-Id: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: secdir <secdir@ietf.org>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 14 Jan 2010 18:06:02 -0500
X-Mailer: Apple Mail (2.936)
Cc: draft-ietf-dnsext-dnssec-gost@tools.ietf.org, dnsext-chairs@tools.ietf.org
Subject: [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: Thu, 14 Jan 2010 23:06:14 -0000

I reviewed this document as part of the security directorate's ongoing  
effort to review all IETF documents being processed by the IESG.   
These comments were written primarily for the benefit of the security  
area directors.  Document editors and WG chairs should treat these  
comments just like any other last call comments.

This document defines formats for DNSKEY, RRSIG, and DS records that  
use the GOST suite of cryptographic algorithms, namely GOST 34.10-2001  
for signing and GOST 34.11-94 for digest computation.

The document is generally clearly written and usable, but I'm  
concerned about how the document manages algorithm parameters. The  
cryptographic computations described in this document all use a single  
set of parameters, even though RFC 4357 defines at least four other  
sets of signing parameters, and parameter selection is permitted by  
several analogous drafts: RFC 3110 (RSA/SHA1 for DNSSEC) allows the  
RSA modulus to be specified, and RFCs 4490 and 4491 (the analogous  
documents for PKIX and CMS) allow the use of arbitrary GOST  
parameters.  "Hard-wiring" algorithm parameters to an algorithm  
number, as this draft does, increases the burden on the algorithm  
number space because it requires a separate number for each  
combination of parameters that can be used.

I also agree with the comments from Steve and Paul that the "SHOULD  
support GOST" in Section 6.1 should be a "MAY".

Detailed comments follow.

--Richard



Section 1, second paragraph:
It would be helpful to refer to the english versions of the algorithm  
descriptions (draft-dolmatov-cryptocom-gost*) at this point.

Section 1, fourth paragraph:
There should be an "and" before "GOST 28147-89".

Section 2.1:

It would be really helpful if you could explain what this sequence of  
bytes means.  Putting on my ASN.1/DER thinking cap, I managed to  
figure out that it's creating a SubjectPublicKeyInfo structure; I  
would suggest saying that, and maybe including a diagram like the  
following (which makes it even clearer that the algorithm parameters  
are being fixed):

SubjectPublicKeyInfo {
    algorithm: AlgorithmIdentifier {
        algorithm: id-GostR3410-2001
        params: GostR3410-2001-PublicKeyParams {
            publicKeyParamSet: id-Gost3410-2001-CryptoPro-A-ParamSet
            digestParamSet: id-Gost3411-94-CryptoProParamSet
            encryptionParamSet: id-Gost3411-94-CryptoProParamSet  
[default]
        }
    }
    subjectPublicKey: GostR3410-2001-PublicKey [64 key bytes]
}

Of course, if implementations are going to be tied to this data  
structure, the only possible parameters they can use are ones that  
have an OID, e.g., those defined in RFC 4357 (this limitation is due  
to the fact that the GostR3410-2001-PublicKeyParams structure only  
allows parameters to be defined by reference).  However, you could  
still allow any OID to be used in the *ParamSet fields and provide  
some simple instructions on how to patch together a  
SubjectPublicKeyInfo structure out of them.

Section 3, second paragraph:
For clarity, it would be helpful to use the notation of RFC 4034 here,  
e.g.:
  hash = GOST3411( RRSIG_RDATA | RR(1) | RR(2) | ... )

Section 3.1, last paragraph:
In order to let people use this example as a test vector, you should  
include the random value that was used to compute this signature.


Section 5:
This section seems unnecessary, since GOST has only one size for keys,  
signatures, and digests.

Section 6.2:
Should the "required" here be "REQUIRED"?

Section 6.3:
This paragraph contradicts Section 3 (and thus RFC 4490), which says  
the signatures are provided in big-endian order.  I think the general  
point is that you're sticking with the byte orders that have been  
previously defined.