Early Review of draft-ietf-dnsext-dnssec-gost-
review-ietf-dnsext-dnssec-gost-secdir-early-kent-2010-01-09-00

Title: 

review of
draft-ietf-dnsext-dnssec-gost-05




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.