Early Review of draft-ietf-dnsext-dnssec-gost-
|Requested rev.||no specific revision (document currently at 07)|
|Team||Security Area Directorate (secdir)|
|Authors||Vasily Dolmatov, Igor Ustinov, Artem Chuprina|
|Draft last updated||2010-01-09|
Secdir Early review of -?? by Stephen Kent
Secdir Early review of -?? by Richard Barnes
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.