Subject: [dnsext] draft-dolmatov-dnsext-dnssec-gost-01 technical & editorial issues

From: Alfred Hönes <[email-masked]>
Date: Thu, 17 Sep 2009 12:25:12 +0200 (MESZ)

Folks,

I have reviewed draft-dolmatov-dnsext-dnssec-gost-01 and found
a number of issues of varying degree of severeness.
Items (1)..(3) below are the hard stuff, the nits are in (4).

(1)

First of all, I'm confused by, and strongly oppose to, the
introduction of little-endian encoding for the on-the-wire
encoding of specific elements of this proposal, as requested
by the last paragraph of Section 2 of this draft.
This is incompatible with the Internet architecture and also
with the ASN.1 framework quoted by the draft, which makes
consistent use of "big-endian" (network) byte order.

Unfortunately, the quoted related RFCs 4490 and 4491
(cf. Section 4 of the draft) already have created bad precedents.
I have filed Errata Notes for these RFCs (EIDs: 1884 and 1885).
As noted there, mixed endianness within one protocol, or even
within a sinfle specification for an extension to a protocol
is a very likely source of confusion, implementation errors,
and, consequentially, interoperability problems.
This practice should be avoided consistently.

(2)

The second inconsistency I found is between Section 6.1,
containing a "SHOULD" requirement ...

|  DNSSEC aware implementations SHOULD be able to support RRSIG and
   DNSKEY resource records created with the GOST algorithms as defined
   in this document.

... and the IANA Considerations in Section 8, which presents new
registry entries with status "OPTIONAL" :

                                        Zone     Trans.
   Value   Algorithm          Mnemonic  Signing  Sec.   References   Status
|  {TBA1}  GOST R 34.10-2001  GOST      Y        *      (this memo)  OPTIONAL

[snip]

   Value   Algorithm        Status
|  {TBA2}  GOST R 34.11-94  OPTIONAL

According to RFC 2119, the normative level of "OPTIONAL" is
equivalent to that of "MAY".

(3) Lack of coverage

The WG already has decided, in recognition of expected deployment
patterns, that NSEC3 has to be considered as an intrinsic part of
the revised DNSSEC specification.  Declaring NSEC3 support as out-
of-scope for this document seems very inappropriate.
Therefore, Section 6.2 should be replaced with positive language.

Note:
  I suspect that the primary target TLD of the draft matter
  (should it be adopted) will most likely also make use of NSEC3
  when deploying DNSSEC, like other 'large' TLDs.

(4) Editorials

Legend for below:

   Sn.n  :  Section n.n

   Pm    :  m-th paragraph

   {old text}
---
   {revised text}

(4a) S1,P4

s/(signatire algorithm)/(signature algorithm)/
         ^                     ^

(4b) S2.1,P1

Please correct:

|  Existing GOST-aware cryptographic libraries at time of this document
                                               v ^          vvvv
|  writing are capable to read GOST public keys via generic X509 API if
   the key is encoded according to RFC 4491 [RFC4491], section 2.3.2.
---
|  Existing GOST-aware cryptographic libraries at the time of this
|  document writing are capable to read GOST public keys via a generic
|  X.509 API if the key is encoded according to RFC 4491 [RFC4491],
   section 2.3.2.
or:
|  Existing GOST-aware cryptographic libraries at the time of writing
|  this document are capable to read GOST public keys via a generic
|  X.509 API if the key is encoded according to RFC 4491 [RFC4491],
   section 2.3.2.

(4c) S3,P1

s/follows the RFC 4490/follows RFC 4490/

(4d) S4,P1

  vv                                                  vv
|  GOST R 34.11-94 digest algorithm is denoted in DS RR by the digest
   type {TBA2}.  [...]
---
|  The GOST R 34.11-94 digest algorithm is denoted in DS RRs by the
   digest type {TBA2}.  [...]

(4e) S5.1
                                vvv
|  According to RFC4357 [RFC4357] key size of GOST public keys MUST be
   512 bits.
---
|  According to RFC4357 [RFC4357], the key size of GOST public keys MUST
   be 512 bits.

(4f) S5.2
               v                        v          v       v
|  According to GOST signature algorithm [GOST3410] size of GOST
|  signature is 512 bit.
---            vvvvv   ^                    vvvvvvvvvvvvvvv          v
|  According to the GOST signature algorithm specification [GOST3410],
|  the size of a GOST signature is 512 bits.
              ^^^                         ^

(4g) S5.3

                                          v       v
|  According to GOST R 34.11-94 [GOST3411] size of GOST digest is 256
|  bit.
---   ^                                   vvvvvv       vvv
|  According to GOST R 34.11-94 [GOST3411], the size of a GOST digest is
|  256 bits.
          ^

(4h) S7,P1

|  Current cryptographic resistance of GOST 34.10-2001 digital signature
   algorithm is estimated as 2**128 operations of elliptic curve point
|  computations on simple modulus 2**256.
---
|  The current cryptographic resistance of the GOST 34.10-2001 digital
   signature algorithm is estimated as 2**128 operations of elliptic
|  curve point computations on a modulus 2**256 field.
or:
|  Currently, the cryptographic resistance of the GOST 34.10-2001
   digital signature algorithm is estimated as 2**128 operations of
|  elliptic curve point computations on a modulus 2**256 field.

(4i) S7,P1

|  Current cryptographic resistance of GOST 34.11-94 hash algorithm is
|  estimated as 2**128 operations of copmutations of step hash function.
   [...]
---                                    ^^
|  The current cryptographic resistance of the GOST 34.11-94 hash
|  algorithm is estimated as 2**128 operations of computations of a step
   hash function.  [...]
or:
|  Currently, the cryptographic resistance of the GOST 34.11-94 hash
|  algorithm is estimated as 2**128 operations of computations of a step
   hash function.  [...]

[ Note:
  I expect you did not envision (bio-chemical) mutation of cops.  :-) ]

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 23 Sep 2009 14:20:08 +0400

> (4) Editorials
Thank you, Alfred.

All editorials are applied and draft is resubmitted under the name 
draft-ietf-dnsext-dnssec-gost-00

After some time I think it will appear in the database.

doL@

---

From: Basil Dolmatov <[email-masked]>
Date: Fri, 25 Sep 2009 13:14:22 +0400

> After some time I think it will appear in the database.
The draft is available.

http://www.ietf.org/id/draft-ietf-dnsext-dnssec-gost-00.txt

dol@