Re: draft-ietf-dnsext-dnssec-gost

[Martin Rex <[e-mail]>]

Andrew Sullivan wrote:
> 
> On Tue, Feb 16, 2010 at 01:18:48PM +0300, Basil Dolmatov wrote:
> >
> > Martin Rex пишет:
> > 
> >> I am somewhat illiterate to crypto math, so I'm wondering whether
> >> it is technicall possible to use a GOST R34.10-1994 key agreement
> >> (ephemeral keys) in conjunction with GOST R34.10-2001 certs&signatures,
> > Never ever interested. ;)
> 
> To address Martin Rex's point, however, we would not need to know
> whether the draft's editors were ever interested, but whether it is
> technically possible.  This seems like a good (and so far unanswered)
> question.

I'm sorry for the confusion and off-topic that I created in the discussion.

The dnssec-gost document appears to be OK in being very explicit and
constrained in its usage of GOST, requiring the GOST R34.10-2001
signature algorithm and implying a single parameter set (A) for
the signatures.

The deprecated GOST R34.10-1994 algorithm is a non-issue for dnssec-gost.
Ensuring that no reference to GOST signatures is without R34.10-2001
qualifier in the document should be sufficient to prevent any potential
confusion.

The use of GOST R34.11 for the hash algorithm should probably also be
changed to include the year GOST R34.11 to prevent confusion with
any future hash algorithms in the GOST R34.11 series.


Mandating a particular parameter set for an ECC crypto algorithm
is perfectly OK for interop.  Whether or not to include
a parameter set identifier in the DNS KEY RR is up to the DNSext
working group (Implementations of GOST are likely to know
all three GOST R34.10-2001 parameter sets listed in rfc-4357).


The byte order of GOST-related values seems to be confusing:

http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-gost-06#section-3

   Quoting RFC 4490:

   "The signature algorithm GOST R 34.10-2001 generates a digital
   signature in the form of two 256-bit numbers, r and s.  Its octet
   string representation consists of 64 octets, where the first 32
   octets contain the big-endian representation of s and the second 32
   octets contain the big-endian representation of r."


http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-gost-06#section-4

   4. DS Resource Records

   GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
   type {TBA2}.The wire format of a digest value is compatible with
   RFC4490 [RFC4490], that is digest is in little-endian representation.


Since there are already RFCs out there using GOST (CMS) and there
are implementations based on drafts (TLS) and maybe some under
evaluation (XMLsec) it seems a little late to ask for "pure"
ordering at this point in time.  Re-using the format/ordering
that is used in existing documents/protocols and implementations
appear to be OK to _me_.  IETF protocols provide more flexibility
at this point than e.g. ASN.1.  To me, it looks like there is
a little mess in GOST byte ordering in various usage scenarios,
so _I_ would not expect interop without interop testing, no matter
what ordering DNSsec defines. :-/


I really appreciate the mentioning of key and hash sizes in the
dnssec-gost document in section 5, because one can not easily
"look it up" in rfc-4357.  (It's in there, but not easy to determine).


-Martin