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.
2 thoughts on ““Crypto-nationalism” and competition in secure DNS”
ICANN clearly has decided to try to do business with Governments as opposed to businesses.
That helps protect ICANN from lawsuits. Also, it places ICANN in a lofty position, over governments.
This is part of a continual movement to the high-ground. It seeks overall control.
Oh dear! Now there would be a legal definition for DNSSEC. Let me look into this.
“During the Term, Registry Operator shall” …
… “comply with RFCs 4033, 4034, 4035, 4509 and 4310 and their successors, [and optionally] with RFC 5155 and its successors.”
While this looks like protocol compliance as usual, I am puzzled: a new gTLD registry operator may well have a business model with little emphasis on IT security in general or DNS data integrity protection (after all, the whole Internet has been run this way until quite recently). You would expect a minimum compliance behavior from such an operator.
…”follow the best practices described in RFC 4641 and its successors.”
Seldom enforceable! In payment system networks where individual participants would seek minimal operating costs, the minimum compliance behavior is ultimately defined by mandatory external auditing provisions, based on detailed operating standards. Nothing similar with DNSSEC where operational practices are documented with the premise that registry operators are willfully seeking effective IT security protections.
…”accept public-key material from child domain names in a secure manner according to industry best practices.”
Is this a joke or a revelation? What are the industry best practices? To which registrar model are they applicable? To which DNS management arrangements are they applicable? Do they require proprietary technology licensing? Actually, this refers to one of the least understood aspects of DNSSEC deployment.
… “publish in its website the practice and policy document (also known as the DNSSEC Policy Statement or DPS) describing key material storage, access and usage for its own keys and the registrants’ trust anchor material.”
Plain bureaucratic overhead. Nowadays, it seems fashionable to make DNSSEC operations similar to X.509 PKI.
Overall, the decision to make DNSSEC support mandatory for new gTLDs is both ill-advised, discriminatory towards new gTLD entrants, counterproductive in view of the DNSSEC goals, and maybe a useless barrier to innovative gTLD business models in which the DNS integrity is only a secondary concern.
Admittedly, this opinion is strongly worded. The above citations are a correct definition of DNSSEC support by a registry operator, if there was an urgent need to use one in a contract language. But the vagueness associated with the technical requirements would have to be addressed as such in contractual provisions, e.g. joint determination of future technical specifications or something else. This shouldn't be all implicitly delegated to the IETF.
Comments are closed.