Crypto-politics creeps into DNSSEC

While the fight over using cryptography to protect personal communications was allegedly “won” during the late 1990s, the battle over using it to protect critical Internet resources is just heating up. News from the recent IETF in San Francisco and RANS conference in Moscow suggests that national crypto laws are now complicating efforts to secure the DNS.

Specifically, supporters of .ru have noted that while they are interested in deploying DNSSEC, there are legal and operational constraints surrounding the current crypto specs in the standard (i.e., RSA signature and SHA digest algorithms) that could make it difficult for Russian based organizations to deploy the protocol. There are now efforts being made to introduce the Russian developed GOST family of algorithms into the protocol.

[Update: An Internet-Draft on producing GOST signature and hash algorithms DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC) has been submitted for adoption by the DNSEXT Working Group.]

In developing DNSSEC, the DNSEXT Working Group recognized the need and designed the protocol to support different algorithms simultaneously. Nonetheless, the protocol documents have mostly made a habit of recommending the use of the RSA signing and SHA hashing algorithms. To some extent this simply reflects the fact that RSA has been incorporated into protocols worldwide (e.g., SSL) and has broad market acceptance. But arguably it is also an artifact of the relatively small social network of authors and mostly American organizations involved in publishing DNSEXT RFCs to date.

DNSSEC evolving to support global Internet

Much like the expansion of the Internet over the past decade, this social network is now changing and so is DNSSEC. Making an intervention at the IETF meeting as a “first time” attendee, Dmitry Burkov pressed the DNSOPS Working Group to remove language from a draft (“DNSSEC Trust Anchor Configuration and Maintenance“) recommending that a zone operator should use the SHA-256 digest algorithm in creating DS resource records (i.e., the hash value of a zone's public key stored in the root zone). His intervention was supported by former DNSEXT co-chair and IAB member Olaf Kolkman, who suggested it would be adequate to simply deprecate the known-to-be-weak SHA-1 digest algorithm. Such a change would implicitly allow zone operators to use the algorithm of their choice.

The request was seemingly well received by the Working Group. As a “global” standards body it would be hard for the IETF to argue that registry operators should not be able to use their preferred algorithms. However, it possibly opens up a political and operational can of worms with respect to signing the root zone.

Crypto control headaches ahead for root signing?

If you follow the logic above, then the root zone operator should also determine what algorithm it would use to sign the root, and resolver operators would configure to validate that algorithm. But a problem arises when resolver operators are constrained by national laws as to what algorithm validation they can implement. And apparently, such constraints on validation of RSA signatures exist in Russia and possibly other countries.

One proposed solution is that those unfortunate resolver operators use DLV, or locally configure trust anchors. But this means they, because they legally use the chosen algorithm, lose the benefits associated with a signed root.

Another approach might be to sign the root zone with a handful of algorithms. The protocol could possibly support this (although there is an ongoing debate in technical and operational community), by allowing resolver operators to signal what type of signed records they can validate. But it would raise another policy problem. There are often export controls and licensing requirements to use signing algorithms, and a single organization may not be able to secure all the necessary licenses.

This all points to the question NTIA asked back in November – who should sign the root? For sake of argument, lets assume the root needs to be signed with more than one algorithm (e.g., RSA, GOST), and briefly reexamine the basic options considered in the NOI:

1. VeriSign signs the root – It's impossible to say until a detailed application is submitted to Russian authorities, but as one of the world's largest purveyors of RSA technology, there could be problems securing a license to use GOST.

2. ICANN signs the root – Given the political oversight by DoC (or even worse, a proposed national security focused Advisory Council), again it could be problematic getting a license to use GOST.

A new organizational model needed?

Assuming the protocol can be made to support the political realities, one option, similar to what IGP proposed in 2005, is a model consisting of a few non-governmental organizations. It is clear from the NOI that the Internet community trusts ICANN. Given this, ICANN could setup a few independent offices globally. Each would be responsible and legally capable of signing the zone with the regions preferred algorithm. They would be jointly responsible for coordinating and compiling the single zone file that is distributed to the root server operators. Then, as suggested on the dnssec-deployment list, resolver operators could see different views of the same root zone. Such a solution would be flexible enough to evolve with future implementation of new algorithms.

There are probably other organizational models worth exploring. It's likely the financial industry has confronted these issues and setup similar global solutions. Another direction might be along the lines of the Federal Bridge Certificate Authority, which enables interoperability among Department PKIs with different security needs in a peer-to-peer fashion.

Comments are closed.