DNSCurve: Usable security for DNS

DNSCurve is a conceptually straightforward integration of link-level cryptography into DNS. Most of the DNSCurve design decisions follow naturally from the fundamental requirement to encrypt and authenticate DNS packets between the client's public key and the server's public key.

Some of the DNSCurve syntax details are less obvious. This page explains how the DNSCurve syntax works around various limitations of existing DNS software. DNSCurve, unlike DNSSEC, was designed to function correctly with existing firewalls, existing DNS-database-management software, etc.

TXT format

In theory, a DNSCurve client is free to send all expanded query packets in streamlined format. The DNSCurve server has announced its capabilities; the DNSCurve client knows that the server can handle more than the original DNS protocol.

However, in practice, clients are sometimes run behind firewalls that reject new packet formats addressed to or from port 53. Those clients are forced to use the TXT format instead. In some cases those clients are also forced to choose the "zero or more additional labels" as the name of the zone served by this server. These constraints consume extra network traffic while reducing confidentiality, so the streamlined format is preferred, but some administrators will be forced to configure clients to use the TXT format.

More complicated query encodings, for example using OPT records, would respect the 255-byte RFC 1035 limit. However, OPT records in query packets are expected to be less likely to pass through firewalls than names exceeding 255 bytes.

The "compression" in the standard DNS packet format is better than nothing, from a space perspective, but obviously can be improved; it would be easy to design more compact formats for the same information. DNSCurve could re-encode the original DNS packet in a more compact format before putting the packet into a cryptographic box. However, this re-encoding would force DNSCurve implementations to inspect the original DNS packet rather than simply passing it along as an uninterpreted string.

Client encoding of public keys

Base 36 would be slightly more compact than base 32, for example encoding 255 bits as 50 bytes instead of 51 bytes. However, this savings is outweighed by the simplicity of base-32 encoding.

Decoding of uppercase protects against the possibility of intermediate firewalls changing lowercase to uppercase. RFC 1034 clearly requires case preservation ("When you receive a domain name or label, you should preserve its case. The rationale for this choice is that we may someday need to add full binary domain names for new services") but this requirement was reportedly violated by some of the google.com DNS servers until recently and perhaps is also violated by some firewalls.

Server encoding of public keys

In theory, public keys could be encoded as a new glue record type. In practice, new record types are a continuing source of interoperability problems (as DNSSEC has encountered) and would require extensive software upgrades (as DNSSEC requires), clearly much worse for deployment than encoding public keys inside NS names.

A complete pre-DNSCurve scan of all labels of all server names in the .com zone found zero labels that could be confused with DNSCurve public keys (exactly 54 bytes, magic string uz5, alphanumeric, no a or e or i or o). There were 7413 diferent labels having 25 or more bytes, and the only label that did not contain a or e or i was the 30-byte string 00000000000000000000000000000. There were just 17 different labels having 50 or more bytes. There were just 3 different labels starting with uz[0123456789], namely the short strings uz11 and uz12 and uz6.

The name testingalongservernamewithdigits0123456789andlettersyz.ns.dnscurve.org has been successfully registered with a popular .org registrar. Presumably there will be some registrars with length limits causing trouble for some users, but those users can switch to registrars with higher length limits, and in any case it should be easy for registrars (and, if necessary, registries) to raise their limits.

In theory, DNS can also use non-alphanumeric names, allowing considerably shorter encodings of public keys. However, in practice, non-alphanumeric names would cause trouble with DNS web interfaces, DNS databases, etc., reducing usability.

Migration mechanisms

The following pattern has been frequently observed in cryptographic protocol design. A novice protocol designer offers a choice of two cryptographic suites, which from a cryptographer's perspective should be labelled "low security" (e.g., 1024-bit RSA, the current DNSSEC choice) and "idiotically low security" (e.g., 640-bit RSA, the original DNSSEC choice). Most users choose the faster option, namely the second. When the second option is publicly broken by a team of academics working in a small computer lab, the users carry out an emergency migration to the first option. When the first option is publicly broken, the users carry out another emergency migration to another option, which hopefully has been added to all relevant software in time. Presumably botnet operators, armed with considerably more computer power, were able to break the same low-security systems years earlier.

DNSCurve does provide a migration path to smoothly switch cryptographic suites in case of disaster. The magic string uz5 distinguishes DNSCurve names not only from existing server names in DNS but also from other DNS extension mechanisms that may be added in the future. For example, uz7 could indicate another cryptographic suite. Caches are required to check each label in the name, rather than just the first label, so that one name can have more than one extension mechanism.

However, DNSCurve does not use migration as an excuse for deploying low-security cryptography. DNSCurve skips years of emergency migrations away from low-security systems, and instead starts with a conservative cryptographic suite that is not expected to be broken until the advent of quantum computers.

Version

This is version 2009.06.22 of the integration.html web page.