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

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 14 Jan 2010 18:06:02 -0500

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.

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 14 Jan 2010 18:43:20 -0500 (EST)

>From the perspective of the DNS world, I think being explicit about 
this is actually pretty handy.  I see benefit in leaving it.

Other than that, I generally concur with the secdir reviews received 
to date, particuarly the lowering of the requirement level.

Also, while I haven't thoroughly reviewed this draft since April 2009 
(when the DNSEXT WG was asking whether to adopt it or not), a couple 
of things jump out, which I'll share now rather than wait for the IETF 
last call:

Section 6.2, on NSEC3 support, is a little vague.  I think the doc 
means "zones signed with the algorithms specified in this document may 
use either NSEC or NSEC3 and validators supporting this algorithm must 
support both NSEC and NSEC3".  I'm not sure my wording is much 
clearer, but a change is needed.

In the IANA considerations, do not use the asterisk.  Just say that 
this algorithm suite isn't being defined for transaction security 
mechanisms.

Also, the IANA considerations section includes the requirement status 
column, which implicitly assumes that we are advancing 
draft-ietf-dnsext-dnssec-registry-fixes-01.  I'm not convinced that's 
going to happen any time soon, particularly given the lackluster 
response to draft-ogud-iana-protocol-maintenance-words, which it 
depends on.  So... that needs to be tracked.  It's not necessary to 
cite registry-fixes, but it probably is necessary to treat it as a 
dependency for publication purposes.

-- Sam

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 15 Jan 2010 10:05:51 -0500

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

>descriptions (draft-dolmatov-cryptocom-gost*) at this point.

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

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

>SubjectPublicKeyInfo structure out of them.

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

>include the random value that was used to compute this signature.

Good points,

>This section seems unnecessary, since GOST has only one size for keys,

I agree but the section is "mostly harmless"

>Should the "required" here be "REQUIRED"?

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

>point is that you're sticking with the byte orders that have been

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

         Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 15 Jan 2010 10:16:04 -0500

At 18:43 14/01/2010, Samuel Weiler wrote:
>>This section seems unnecessary, since GOST has only one size for 
>>keys, signatures, and digests.
>
>Also, while I haven't thoroughly reviewed this draft since April 
>2009 (when the DNSEXT WG was asking whether to adopt it or not), a 
>couple of things jump out, which I'll share now rather than wait for 
>the IETF last call:

>means "zones signed with the algorithms specified in this document 
>may use either NSEC or NSEC3 and validators supporting this 
>algorithm must support both NSEC and NSEC3".  I'm not sure my 
>wording is much clearer, but a change is needed.
>
>this algorithm suite isn't being defined for transaction security mechanisms.

I agree the document should say one way or the other, not supporting
Transaction security is easier on all.

>Also, the IANA considerations section includes the requirement 
>status column, which implicitly assumes that we are advancing 
>draft-ietf-dnsext-dnssec-registry-fixes-01.  I'm not convinced 
>that's going to happen any time soon, particularly given the 
>lackluster response to draft-ogud-iana-protocol-maintenance-words, 
>which it depends on.  So... that needs to be tracked.  It's not 
>necessary to cite registry-fixes, but it probably is necessary to 
>treat it as a dependency for publication purposes.

Good point, will talk to AD about this before the document
goes to the IESG after IETF LC ends.

         Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Jan 2010 12:32:22 -0800

At 10:16 AM -0500 1/15/10, Olafur Gudmundsson wrote:
>>Also, the IANA considerations section includes the requirement status column, which implicitly assumes that we are advancing draft-ietf-dnsext-dnssec-registry-fixes-01.  I'm not convinced that's going to happen any time soon, particularly given the lackluster response to draft-ogud-iana-protocol-maintenance-words, which it depends on.  So... that needs to be tracked.  It's not necessary to cite registry-fixes, but it probably is necessary to treat it as a dependency for publication purposes.
>

Will you also bring this to the WG?