New IAB Chair Defends DNSSEC

bednarz writes "Olaf Kolkman, the new chair of the Internet Architecture Board, says that DNSSEC — an approach to authenticating DNS traffic that has been slow to take off — is not a failure. 'It is taking a while to percolate into software, and for that software to percolate into the market, and for people to adapt their environments to deploy and operate DNSSEC. The deployment is hindered by a chicken-and-egg problem'."

Bernstein rips DNSSEC a new a-hole

[Anonymous Coward]

D. J. Bernstein [slashdot.org]
Internet publication [slashdot.org]
djbdns [slashdot.org] DNS forgery I've given a few talks on ``The DNS security mess'': 2003.02.11 [slashdot.org] (slides available). 2003.03.18 [slashdot.org] (slides available). 2004.04.28 [slashdot.org] (slides available). An attacker with access to your network can easily forge responses to your computer's DNS requests. He can steal your outgoing mail, for example, and intercept your ``secure'' [slashdot.org] web transactions.

If you're running a DNS server, an attacker with access to your network can easily forge responses from that DNS server to other people. He can steal your incoming mail, for example, and replace your web pages.

An attacker from anywhere on the Internet, without access to the client network and without access to the server network, can also forge responses, although not so easily. In particular, he has to guess the query time, the DNS ID (16 bits), and the DNS query port (15-16 bits). The dnscache [slashdot.org] program uses a cryptographic generator for the ID and query port to make them extremely difficult to predict. However,

• an attacker who makes a few billion random guesses is likely to succeed at least once;
• tens of millions of guesses are adequate with a colliding attack;
• against BIND, a hundred thousand guesses are adequate, because BIND keeps using the same port for every query; and
• against old versions of BIND, a thousand guesses are adequate with a colliding attack.

As of November 2002, CERT is panicking because they didn't realize how trivial this was, even though I spelled it out in a posting [slashdot.org] in July 2001.

Larger cookies in the DNS protocol could make blind attacks practically impossible. (Caches could achieve a similar effect without protocol changes by repeating queries a bunch of times with different ports and IDs, at the expense of speed and reliability.) However, attackers with access to the network would still be able to forge DNS responses. Public-key signature systems Modern cryptography offers a tool to prevent forgeries: a public-key signature system. In short:

• You create and publish a key.
• You---and, if the system is secure, nobody but you---can sign a document under that key.
• Anyone can verify that the document was signed under your key.

The signature is a complicated mathematical function of the document and the key. DNSSEC: theory and practice DNSSEC is a project to have a central company, Network Solutions, sign all the .com DNS records. Here's the idea, proposed in 1993:

• Network Solutions creates and publishes a key.
• Each *.com creates a key and signs its own DNS records. Yahoo, for example, creates a key and signs the yahoo.com DNS records under that key.
• Network Solutions signs each *.com key. Yahoo, for example, gives its key to Network Solutions through some secure channel, and Network Solutions signs a document identifying that key as the yahoo.com key.
• Computers around the Internet are given the Network Solutions key, and begin rejecting DNS records that aren't accompanied by the appropriate signatures.

However, as of November 2002, Network Solutions simply isn't doing this. There is no Network Solutions key. There are no Network Solutions *.com signatures. There is no secure channel---in fact, no mechanism at all---for Network Solutions to collect *.com keys in the first place.

Even worse, the DNSSEC protocol is still undergoing massive changes. As Paul Vixie wrote on 2002.11.21:

We are still doing basic research on what kind of data model will work for dns security. After three or four times of

DNSSEC doesn't seem very useful

[cswiger]

Adding cryptography or secure signing of zone files might be useful if you were either trying to keep info private from eavesdroppers, or wanted to verify that when you went to www.mybank.com, the address record you looked up was actually signed by your bank.

But nobody (or not many people) use DNSSEC to encrypt zone transfers, and almost everybody hits a recursive nameserver run by your ISP or perhaps local to your company's network, which means that the end-user is never going to know whether the DNS query they issued returned a signed response or was forged from the authoritative DNS server. When done well, DNS spoofing can completely mangle a lot of network interactions one would really like to take for granted, such as being able to look up Microsoft's windowsupdate site, Apple's software update, anti-virus update sites, and so forth.

Right now, you have to dig deep into the bowels of BIND to even notice whether a zone has been signed, and there is pretty much zero feedback about that status which propogates back to a client like a web browser or your platform-specific software update mechanism. Until that changes, I don't see DNSSEC doing anything really useful to solve the genuine problems which it might be useful to solve. If all you wanted was a way to encrypt zone transfers, using rsync over SSH is a lot easier to deal with.

DNSSEC isn't being implemented

[Colin Smith]

Because MS don't support it, and Windows makes up 90% of client systems. They don't support it because they have a competing non standard embraced and extended system of their own.

 

Re:Authenticating DNS provides an audit trail...

[Watson Ladd]

They already can do that by recording the queries and responses. DNSSEC doesn't offer anything new in terms of traceability. So did you use Tor to post that comment?

DNS poisoning

[jd]

Certainly this is more common than it once was. It is one of the nastiest of the still-effective low-level attacks. Most of the other fundamental stuff (BGP, for example) has improved on the security front. Now, if DNS is only run on dedicated DNS servers, you can just IPSEC between them, but IPSEC is not getting deployed much, either.

So what's the real reason none of this is getting used? "No perceived need" is clearly bogus, so we can dispense with that. Seems to me that the real reason is that DNSSEC and IPSEC place overheads on the system, but most data centers and ISPs run DNS on really cheap, natty boxes. If service was degraded still further from security, there would be a lot of complaints. However, it's either that or putting essential services on much higher-performance boxes, and anyone who has ever worked in such organizations know that management would turn to satanic forces to keep their customers before spending a single extra buck on hardware upgrades.

WORKING DNSSEC spec needed and wasn't available

[dwheeler]

The fundamental problem is that a WORKING DNSSEC specification hasn't been available. We really DO need what DNSSEC was intended to provide - i.e., if you type in a DNS name, your browser should be able to automatically get its data (IP address, etc.) and use crypto to ensure that it really is the authentic, unmodified data. The problems in DNS have been publicly known since at least 1995.

But a USEFUL spec hasn't been available until perhaps this year. The real story of DNSSEC is a painful story of attempt after attempt, all of them failing to meet the need.

In 1997 they released RFC 2065, which really didn't work, and in 1999 they released RFC 2535 and thought they were done. But RFC 2535 was completely impractical; it had an absurdly complicated siz-message protocol to do key exchanges for a child, and changes in a parent required all child keys to be re-signed (if the ".com" zone changed its public key, it would have to send 22 million records (because it would need to update all of the signatures in all of its children)). RFC 2535 was fine for a toy local network, but completely useless for the Internet. This should have been obvious, but the DNS group didn't accept that this was a problem until 2001 or so.

They then made a big change to DNSSEC, to use "delegation signer (DS) resource records" to provide an additional level of indirection at delegation points between a parent and child zone. In the new approach, when a child's master public key changes, instead of having to have six messages for every record in the child, there is one simple message: the child sends the new public key to its parent (signed, of course). Parents simply store one master public key for each child; this is much more practical. This means that a little data is pushed to the parent, instead of massive amounts of data being exchanged between the parent and children. This does mean that clients have to do a little more work when verifying keys. More specifically, verifying a DNS zone's KEY RRset requires two signature verification operations instead of the one required by RFC 2535 (there is no impact on the number of signatures verified for other types of RRsets). Most view this as a small price to pay, since it changes DNSSEC so it is more practical to deploy.

But the DNSSEC developers were STILL under the illusion that all DNS data, transitively, is public data. Any peek at a book on how to configure DNS systems clearly states that it's best practice to hide as much data about your organization's internals as you can. But the DNSSEC members didn't understand that, and explicitly permitted zone walking... making it impossible to hide private data. As far as most users were concerned, DNSSEC got rid of one security problem by creating a new one: loss of confidentiality. Even worse, when early adopters tried out DNSSEC and told the EITF group that they would NOT use DNSSEC until this was fixed, their comments were ignored. Finally, DENIC had to explain to the IETF explaining that DNSSEC's zone enumeration issue violates Germany's Federal Data Protection Act, and that other European countries have similar privacy laws forbidding the public release of certain kinds of information. In other words, it is ILLEGAL to deploy DNSSEC in many countries, because it forces private information to become public information.

So they finally decided to create NSEC3, an extension to DNSSEC that should reduce the zone walking problem and hopefully make DNSSEC reasonable (and legal!) to deploy. But NSEC3 is wet behind the ears.

Is there really any shock that a specification wasn't widely deployed when (1) technical problems made it impossible to deploy on the internet, and (2) fundamental security problems (like zone enumeration) made it illegal to deploy while creating new security problems? More info on DNSSEC is on Wikipedia [wikipedia.org].

DNSSEC and zone transfers

[shani]

But nobody (or not many people) use DNSSEC to encrypt zone transfers, and almost everybody hits a recursive nameserver run by your ISP or perhaps local to your company's network, which means that the end-user is never going to know whether the DNS query they issued returned a signed response or was forged from the authoritative DNS server.

First, lets clear up some misconceptions here.

DNSSEC never encrypts transfers, whether zone transfers or other queries. One of the design decisions (documented in the 1990s) is that DNS is a public protocol. So there is no provision to hide data. DNSSEC rather allows cryptographically signed responses, so you can authenticate that the information came from the right place.

Also, the attack you describe (giving bogus data to secondaries) is exactly one of the problems DNSSEC is designed to protect against. With DNSSEC queries (NSEC or NSEC3), it is not possible to spoof queries merely by sending secondaries bad data via a zone transfer (AXFR or IXFR). Like all public key cryptography, it is not possible to sign a DNS record without the private key. The client can check to verify that replies have been signed by the holder of the private key for the zone.

Also, when people talk about using DNSSEC for zone transfers, they really mean using TSIG. Unlike NSEC or NSEC3, which uses public key, TSIG uses a shared key. In this way, it's basically a password that the primary and secondary servers agree on. It's much simpler to understand and implement than NSEC/NSEC3, because the problem is simpler.

As for your claim that nobody uses DNSSEC for zone transfers, I think this is not true. TSIG has been around for a long time, and is easy to use. Sites that host large numbers of DNS zones, either as primary or secondary, often require TSIG (or at least strongly encourage it). Also, a lot of people who run their own primary/secondary infrastructure use it between servers (this is of course easier if you control all servers for a zone).

As to what percentage of zone transfers are TSIG protected... this is an impossible number to get. So I propose the further discussion needs to be held over beers at a pub somewhere, since there is no actual data. ;)

DNSSEC Trust, DLV

[shani]

As long as DNS root servers are unsigned, how can the regular DNS servers start to implement that? Sweden and Puerto Rico???

In the ideal world, to verify that a DNS answer is correct, you start the chain of trust at the root, then follow to a top-level domain (TLD), and continue on down the tree until you get to your final answer.

If at any point a zone does not have a DS record pointing to it, then the chain of trust is broken, and the ultimate answer will be unsecured. But this follows the usual DNS hierarchy... if your parent provides DNSSEC, then you have the option to secure your zone.

But since the root is not signed, you cannot start the chain of trust at the root. A resolver needs to have the public key configured for each of the zones that it knows are secured... these zones are called "trust anchors".

The problem with this is that there are hundreds of zones in the root. Finding the public key for each zone is a very heavy administrative task, as is getting new keys when the old ones expire. Going further down in the tree makes things even worse.

One proposed solution, designed as a temporary measure until the root is signed, is DLV. With DLV, you use normal DNSSEC, but if you don't find a trust anchor anywhere in the tree, then you look at another special tree.

So, say you were looking for "www.mydomain.example.com", and there was no trust anchor. You would then look in a DLV server for "www.mydomain.example.com", then "mydomain.example.com", then "example.com", and finally ".com". If at any point a DLV entry was found, you would follow that chain of trust.

What DLV does is basically create a "second root" just for securing DNS. It's not a good solution, but it is better than nothing. The main goal is to allow people to use DNSSEC easily while waiting for ICANN to sign the root.

<full_disclosure>
The DLV solution is being pushed by my company, ISC [isc.org]. We run a DLV registry [isc.org], which is free for all to both publish data in and query.
</full_disclosure>

Actually... they will.

[hardaker]

Actually....

They are going to. [dnssec-deployment.org]

Re:Nice in theory...

[hardaker]

So I'm really interested whether we will see any implementations of this.

oh, [wikipedia.org] I [nlnetlabs.nl] think [dnssec-tools.org] we [dnssec-deployment.org] may [cpan.org] see [verisignlabs.com] a [nominum.com] few [nlnetlabs.nl]