[secdir] review of draft-ietf-dnsext-dnssec-gost-05

[Stephen Kent <[e-mail]>]

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.

Since several SECDIR members are reviewing 
draft-ietf-dnsext-dnssec-gost-05 I have chosen to focus on one aspect 
of the document, i.e., the statement that support for GOST algorithms 
is a SHOULD (Section 6.1) for all DNSSEC aware implementations. I 
think this is an inappropriate characterization for the level of 
support that ought to be accorded an algorithm of this type. I 
explain my rationale for this assertion below.

GOST is an example of what I would term a "national" crypto 
algorithm. I characterize an algorithm as "national" if use of the 
algorithm is mandated by a government (within its sphere of 
influence, for some or all application contexts), but the algorithm 
otherwise is not widely adopted. The GOST set of algorithms are one 
such example. Others (chosen form the space of symmetric algorithms) 
include Camellia (Japan), SKIPJACK (US), SEED (Korea), and SMS4 
(China, for WAPI). AES and DES are not "national"  algorithms.  Even 
though they were published by NIST as FIPS, both were very widely 
adopted outside of the national context in which use is (was) 
mandated. This illustrates that the designation of an algorithm as 
"national" can change over time.

Other IETF WGs (e.g., IPsec, S/MIME, OPGP, and TLS) have adopted a 
policy of publishing RFCs that describe how to use one or more 
national algorithms in the context of a protocol. However, in these 
WGs, support for the algorithm is optional, i.e., a MAY in RFC 2119 
parlance. These RFCs define how to use a national algorithm IF one 
chooses to implement it. They do not require support for the 
algorithm by making it a SHOULD or MUST. This approach allows the 
IETF to publish RFCs that deal with a wide range of crypto algorithms 
(national and otherwise) without prejudice, without engaging in a 
protracted debate about whether all of these algorithms are equally 
"worthy" etc. These WGs also define a small number of mandatory (MUST 
or SHOULD), non-national algorithms, to promote interoperability.

I think the convention adopted by other WGs is appropriate for DNESEC 
as well. As a result, I suggest that this document be modified to 
specify support for GOST algorithms as a MAY.