The public forum at the recent ICANN-Seoul meeting included an exchange between IGP's Milton Mueller and ICANN Board member Steve Crocker concerning cryptographic algorithms used in DNSSEC and the requirement in ICANN's new gTLD application to deploy DNSSEC. Both raised points which bear repeating and further elaboration of the underlying competition issues that comes with signing the root.
Mueller raised the issue that signing the root with RSA is unacceptable to applicants from certain countries. Apparently, because of national laws, it may be difficult for entities under certain jurisdictions to validate strong RSA signatures on Internet infrastructure data. The practical result is that an ICANN-NTIA-VeriSign provided single trust anchor for authenticating the DNS will serve existing gTLDs and their users well, but could be meaningless for some new IDN TLDs, particularly BRIC countries with dramatic growth in Internet users. Or as Mueller put it, ICANN “may be, indeed, eliminating the competition in IDN gTLDs from those countries and possibly other countries.”
Understandably viewing this from a technical perspective, Crocker (who is also the chair of the SSAC and CEO of Shinkuro, a company contracted by DHS to promote DNSSEC deployment and active in the IETF's DNSEXT working group) indicated the DNSSEC protocol is designed to handle use of multiple algorithms, and that a country can use its preferred algorithm and “their own trust anchors for whatever zones they want.” While Crocker questioned the advisability of doing this (I assume for interoperability reasons), he stated that the protocol is flexible enough to accommodate it. The main impediment, according to Crocker, was getting those algorithms specified for the DNSSEC protocol within the IETF standardization process. He also said point blank if countries are “uncomfortable with the algorithms being used to protect the root, there's not a whole lot that can be done to change that.”
A competitor to RSA secured DNS?
Over the past several months, Cryptocom, a Russian company, has painstakingly developed and advanced the necessary protocol documents through the IETF for using the Russian GOST cryptographic standard with DNSSEC. According to a leading expert in the DNSEXT Working Group, the sponsor has met or exceeded every procedural or technical bar set. The Internet-Drafts have now reached last call in the Working Group, where the outcome can be advancement to IESG for approval or for revisions or rejection by the Working Group.
The Working Group has been mostly silent during the development of the Russian GOST Internet-Drafts. One exception has been the concurrent development of an I-D to change the requirement (from requiring a standards track RFC to requiring a published RFC of any type) for assignment of a “codepoint” identifier in the DNS Security algorithm numbers registry maintained by the IANA. The important issue here is that GOST will need a code point in order to be deployed widely, and barring any unexpected action by the Working Group or IESG it should become eligible for code point assignment. How this develops at next week's IETF meeting in Hiroshima and afterward is definitely worth watching.
Setting standards vs. picking favorites
From the perspective of a disinterested academic, the more the DNSSEC saga plods on, the more it starts to look like a typical international standardization episode. One main historical lesson from standardization is that national governments influence standards to prop up their domestic companies and seek dominance in the global marketplace. While technical challenges are ever present and can derail a standard, it is the political-economic motivations of various actors which are interesting and often determine outcomes.
One reason the US, Japan, and Europe supported the development of Internet standards in the IETF was to avoid national or regional influence in the marketplace. Over the years, the IETF has tried to avoid introducing capabilities into protocols that created conflicts with the transnational nature of the Internet's infrastructure and with varying national laws. The IETF's credibility still rests on this impartiality and deference to technical acumen and persuasion.
The trouble here is that the IETF was not responsible for determining how DNSSEC would be deployed at the root. It could have been, but that wasn't the path chosen by the U.S. Department of Commerce, who still oversees any changes to the DNS root and its management. Instead, those requirements were drafted jointly by the NTIA and NIST, with limited consultation from the Internet technical community as well as root zone management partners ICANN and VeriSign – all parties interested in maintaining the existing governance arrangements of the DNS root. Given this, it isn't surprising at all that the end result could cause other countries or firms concern.