Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-gost-03.txt

From: [email-masked]
Date: Thu, 12 Nov 2009 09:15:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
	Author(s)       : V. Dolmatov, et al.
	Filename        : draft-ietf-dnsext-dnssec-gost-03.txt
	Pages           : 8
	Date            : 2009-11-12

This document describes how to produce signature and hash using 
GOST algorithms for DNSKEY, RRSIG and DS resource records for use in
the Domain Name System Security Extensions (DNSSEC, RFC 4033, 
RFC 4034, and RFC 4035).

V.Dolmatov

  Expires May  10, 2010

[page 1]

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-gost-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Chris Thompson <[email-masked]>
Date: 17 Nov 2009 17:54:54 +0000

I am a bit unclear about the first two "parameter" octets in
the DNSKEY public key data:

>  The only valid value for both parameters octets is 0.
>  Other parameters octets values are reserved for future use.

Is this essentially a method of sub-typing the "TBA1" algorithm
code? And if so, ought not the same parameter octets be present
in the corresponding DS records?

Specifically, what is an implementation to do if it finds only
DNSKEY records with parameter octets that it does not understand
(currently, any non-zero values)? Treat the zone as insecure,
or as bogus?

Nit in section 7:

> Currently, the cryptographic resistance of the GOST 34.10-2001
> digital signature algorithm is estimated as 2**128 operations
> of multiple elliptic curve point computations on prime modulus
> 2**256.

2**256 isn't prime! Presumably "prime modulus of order 2**256"
or the like is meant.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Nov 2009 11:28:43 +1100

> (currently, any non-zero values)? Treat the zone as insecure,

Anything other than zero's wouldn't have this dnskey algorithm code.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Michael Graff <[email-masked]>
Date: Tue, 17 Nov 2009 19:43:22 -0600

> Anything other than zero's wouldn't have this dnskey algorithm code.

Then why include them in the key format that is stored and transmitted?

- --Michael

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Nov 2009 13:13:07 +1100

In message <[email-masked]>, Michael Graff writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Andrews wrote:
> 

Presumably because it make it easier to use existing software which is
expecting these fields.

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 18 Nov 2009 11:12:32 +0300

> Presumably because it make it easier to use existing software which is
Definitely so.

dol@

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 18 Nov 2009 11:24:47 +0300

> 2**256 isn't prime! Presumably "prime modulus of order 2**256"
Yes, thanks, will be fixed.

dol@

---

From: Chris Thompson <[email-masked]>
Date: 18 Nov 2009 11:13:32 +0000

>In message <[email-masked]>, Chris Thompson writes:
[... snip ...]
>Anything other than zero's wouldn't have this dnskey algorithm code.

That would be a satisfactory resolution - maybe the draft ought to
make that clearer if it is indeed the intent? Maybe

| Other parameters octets values are reserved for future use.

should have "with a different algorithm number" added?