Re: draft-ietf-dnsext-dnssec-gost

[Ran Atkinson <[e-mail]>]

All,

hHere are at least 2 issues under discussion within this thread.
I'd like to address them separately, but in the same note.

(1) Quality of GOST specification

While I'm very happy to see any algorithm publicly documented
in an I-D or RFC, I agree with Martin Rex that the current
RFC-4357 on GOST 3410-2001 is not sufficiently clear and 
complete to easily lead to entirely-independent interoperable 
implementations.  It ought to be possible for a non-Russian,
non-certified, implementation to interoperate with any other
implementation of the same algorithm -- from an implementer 
reading the RFC alone.

Martin Rex's notes to the IETF list:
A) http://www.ietf.org/mail-archive/web/ietf/current/msg60250.html
B) http://www.ietf.org/mail-archive/web/ietf/current/msg60253.html

I share Martin Rex's desire for some clarifications to that
fundamental document, and I also share his concern that the 
RFC specifying GOST does not specify what an implementation 
ought to do when it encounters "signatures with other parameter 
sets".  Such a revision ought to make more clear, perhaps
in "Security Considerations" as Martin Rex earlier suggested,
that GOST-3410-2001 is entirely separate from GOST 3410-94.
That fact is NOT obvious from reading RFC-4357 and is quite
relevant to implementers (of either version) of GOST 3410.
In that revision to RFC-4357, I'd love to see an Appendix with 
some test vectors for GOST, as well.  Documenting a wide range
of suitable test vectors can be extremely helpful in verifying 
that a particular implementation of some algorithm is operating 
correctly, which in turn is fundamental to protocol interoperability.  
(RFC-4231 provides an example of test vectors for some other 
openly specified algorithms.)


(2) DNSsec use of GOST specification

For the several reasons various folks have already expressed 
on the IETF list, and also for the reasons above in (1), 
I share the view that GOST should be "MAY" rather than "SHOULD" 
for use in DNS Security.

Yours,

R. Atkinson