Skip to main content

Early Review of draft-ietf-dnsext-dnssec-gost-

Request Review of draft-ietf-dnsext-dnssec-gost
Requested revision No specific revision (document currently at 07)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2010-03-02
Requested 2009-12-24
Authors Vasily Dolmatov , Igor Ustinov , Artem Chuprina
I-D last updated 2010-01-14
Completed reviews Secdir Early review of -?? by Stephen Kent
Secdir Early review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes
State Completed
Request Early review on draft-ietf-dnsext-dnssec-gost by Security Area Directorate Assigned
Completed 2010-01-14
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.


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  


   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,  


 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.