Slashdot Mirror
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'."
Development and implementation, has been slow or nonexistent across the board.. But that doesn't mean it is a failure..
No, ok, I'll grant him that.. But sometimes no matter how useful (or perhaps good) an idea is, it just doesn't happen. Sorry mate..
In the interview he says that it's a bit of a "chicken and the egg" problem, yet while he lists a few minor adopters who have it somewhat deployed, he has no concrete solution to the problem..
Any type of dns security, or verification is certainly interesting, and probably beneficial, but DNS is 25-30 years old, and still works, there just isn't a compelling reason to augment it for most people who deal with keeping DNS servers running...
My rantings, only longer and with better spelling..
My personal motivation to work in this space is that I want to allow my now 3- and 6-year old children to make use of the Internet based on the same core principles as I now know them.
You really want your 3- and 6-year olds to inherit the spam-ridden porn-fest we have today? That's just mean. Think of the children!
Internet publication
djbdns DNS forgery I've given a few talks on ``The DNS security mess'': 2003.02.11 (slides available). 2003.03.18 (slides available). 2004.04.28 (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'' 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 program uses a cryptographic generator for the ID and query port to make them extremely difficult to predict. However,
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 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:
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:
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:
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.
"The human race's favorite method for being in control of the facts is to ignore them." -Celia Green
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.
Deleted
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?
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
Nothing about DNSSEC has improved since wrote about it last year:
DNSSEC is a huge waste of time. For a fraction of the effort, we could have pervasive opportunistic VPN-style connections. Or we could clean up the mess of insecure code that currently provides our core infrastructure. Or a unified standard secure email transport based on GPG/PGP. Or a concerted effort to solve the cross-site scripting problem. You could come up with a way to secure and authenticate the AOL OSCAR IM protocol and still do more good than DNSSEC ever will.
Of course, the IETF people will never admit this. The IETF types used to define themselves by making fun of the OSI X-standards people; "rough consensus and working code!". The Internet won, CLNP lost. Where do you think all those standards bureaucrats you made fun of in the OSI groups went? That's right; to IETF working groups.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
No, spam is not a freedom of speech issue. For example, no one's freedom of speech permits them to fill up the HR guy's email box to the point where it is almost unusable. The mailbox exists for the purpose of business communications.
Freedom of speech does not permit you to litter your neighbors house with leaflets, not matter what they say.
I don't think people are going to far in battling spam; we recently switched to a new mail server, which has spam filtering built in using several filters, and our HR person is very grateful. Now instead of 300 spam emails, and 3 legit ones, he only has the three legit ones, and possibly a few spam.
On the other hand, no one is being forced to look at a porn site. Anyone that wants to see it can, and anyone that doesn't go browsing for it.
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.