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

[Olafur Gudmundsson <[e-mail]>]

At 18:06 14/01/2010, Richard L. Barnes wrote:
>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.

Richard
thanks for your excellent review,
As for the hard-wiring of one curve that is intentional.
DNS is a "broadcast" protocol thus the signer can not make any assumptions
about the capabilities of parties that may want to verify the
data. For this reason having explicit curve specified as better from
operational perspective. The only reason to define a new curve is to
either get a better hash algorithm or a stronger/larger curve.
The other options do not provide any of these.


>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.

Good point, the document should be updated to refer to both.

>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]
>}

To DNS people these are simply bytes and we do not really mean,
but your point is taken and I will see about adding this to the
document.

>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.

I think this goes against our intent of tight specification of what
is allowed.

>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.
>

Good points,

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

I agree but the section is "mostly harmless"

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

That should read
"DNSSEC-GOST implementations are REQUIRED to support both NSEC and
NSEC3 for GOST signed zones."


>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.
>

I read this section to only cover the DNSKEY material not the signature.

         Olafur