New IAB Chair Defends DNSSEC 49
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'."
DNSSEC spec is flawed (Score:-1, Troll)
Re:DNSSEC spec is flawed (Score:0)
So let me get this straight... (Score:4, Insightful)
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...
Re:So let me get this straight... (Score:2, Insightful)
Re:So let me get this straight... (Score:2)
Re:So let me get this straight... (Score:4, Insightful)
I believe there was a quote by a president who commented on the telephone, that went along the lines of, "It's a marvelous invention, but who would ever want one?"
Re:So let me get this straight... (Score:1)
Later, the definitions were changed to include the term "that interferes with everyday life" or something similar. So now, someone who double checks their door locks isn't OCD, just cautious, as long as they don't spend an hour a night doing it.
Likewise IPV6 - if the "problems" with IPV4 don't substantially affect the users, then they aren't problems. They may turn into problems in the future, when users start being affected, but they are not now. Saying "people just don't understand" isn't going to get a lot of traction - it insults the intelligence of the very audience one is trying to convince.
Re:So let me get this straight... (Score:2)
But you are correct in that the ideal model isn't a requirement for a productive system. It's just that it seemed like the parent poster was caught in an infinitly incremental, good-enough mindset, which I object to.
DNSSEC isn't being implemented (Score:4, Informative)
Re:DNSSEC isn't being implemented (Score:0)
Re:DNSSEC isn't being implemented (Score:1)
Actually... they will. (Score:3, Informative)
They are going to. [dnssec-deployment.org]
DNS poisoning (Score:4, Informative)
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.
Alphabet attacked (Score:1)
Personal motivation? (Score:4, Funny)
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!
Re:Personal motivation? (Score:5, Funny)
what do spam and porn have in common? (Score:2)
We all hate spam, but the lengths to which some people are willing to go to get rid of it is ridiculous.
Re:what do spam and porn have in common? (Score:3, Insightful)
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.
Re:Personal motivation? (Score:3, Interesting)
I don't get this porn fest thing. I use the interwebs all the time, and barely ever see any porn. Where is this porn of which you speak?
The core principle of the internet to me is that anyone can edit it/add to it, or take it in some new direction.
We have Wikipedia, 'Ask a Ninja' and Red vs Blue now. Three things I never would have thought of when I first plugged my 33k modem in, many years ago. My contribution to the web's main attribute is that people keep visiting my site and downloading because they think its a mod for Wow (confusion in the name). Then they discover its really boring...
Bernstein rips DNSSEC a new a-hole (Score:4, Informative)
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,
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:
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:
please repair links (Score:0)
Re:Bernstein rips DNSSEC a new a-hole (Score:1, Insightful)
>easily forge responses from that DNS server to other people. He can steal
>your incoming mail, for example, and replace your web pages.
If an attacker has access to your network, he can do a lot of things.
Re:Bernstein rips DNSSEC a new a-hole (Score:0)
In that, it is similar to IPv6. Installing IPv6 will give you zillion new addresses but (almost) nobody to talk to.
Nice in theory... (Score:0)
Re:Nice in theory... (Score:2)
As I see it, security is like insurance. It's a cost that gives you nothing... until after you've had a problem.
Maybe the costs of DNSSEC outweigh the benefits. I think that's probably true today... for lower-level domains at least. For organizations who's main job is providing DNS (like the root servers, ccTLDs, and so on) then the cost is not so high and the potential risks are great.
The costs of DNSSEC will start to decrease as the technology gets more mature. It's currently moving from bleeding-edge to cutting-edge.
Re:Nice in theory... (Score:3, Informative)
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]
Amanda Tapping == Security? (Score:2)
FROSTY PISS (Score:-1, Troll)
DNSSEC doesn't seem very useful (Score:3, Informative)
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.
Re:DNSSEC doesn't seem very useful (Score:2)
Allowing the bank to sign dns records on the other hand is a worthwhile objective that could kill DNS spoofing.
The only trick to signed DNS records is that you'd need access to the banks public key to verify the signatures, which could be a problem, because you couldn't rely on unsigned dns to give you the address of the server from which to download the public key. A true chicken and egg problem.
But the same sort of solution that browsers use with embedded ssl root certificates could probably work. Known clearinghouses for public keys are established, where banks etc can host their public keys, and where the dns clients have the public keys for the clearinghouse built in. (And like browsers, additional authorities can be manually added/removed by the user, etc.)
A major corp like a bank would be effectively forced to use one of the built in key hosts to save their users the hassle of installing a key manually, but for private corporate uses etc that wouldnt' be necessary.
Of course, I wrote all that without knowing what DNSSEC actually does, so I might have just regurgitated the essentials of what DNSSEC already does.
Re:DNSSEC doesn't seem very useful (Score:3, Interesting)
DNSSEC doesn't encrypt anything, just authenticate. And it fits into the DNS design of caching and recursive nameservers - believe your ISP's server will give you something that proves the answer came from the authoritative server at some time less than $TTL seconds ago. Now, I don't remember if your ISP's nameserver has to have special DNSSEC support or not to pass that information to you...probably yes, which is another infrastructure hurdle.
I'd take advantage of DNSSEC if the infrastructure were there - including a public key in a DNSSEC-authenticated zone would be a good way to authenticate a host. There are two other ways in common use by the clients you mentioned, and neither is quite satisfactory:
In fact, I just googled for "ssh dnssec" and it looks like someone has already written the code for this.
New protocols could rely on DNSSEC instead, and there are probably other protocols like ssh that could be retrofitted easily.
I'm not holding my breath on the infrastructure, though. It's been a while since I've looked at DNSSEC, but IIRC most of the benefits don't come until it's deployed from the root on down. Until .org uses DNSSEC, I can't really use it for slamb.org. I could manually add slamb.org's key into my client software maybe, but that's really not much better than creating my own root certificate for existing PKI mechanisms.
DNSSEC and zone transfers (Score:4, Informative)
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.
DNS Roots (Score:1)
DNSSEC Trust, DLV (Score:3, Informative)
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>
Authenticating DNS provides an audit trail... (Score:3, Insightful)
EVERYTHING the internet stands for (and created) will be vaporized by corporate control of it.
Bloggers - you'll become accountable for what you say
Hosters - you'll become responsible for your clients and what they upload
ad nausem...
No thanks. I like the internet as it is.
Re:Authenticating DNS provides an audit trail... (Score:4, Informative)
Re:Authenticating DNS provides an audit trail... (Score:2)
So a secure DNS system does not help protect us from forged DNS responses? What exactly is your reasoning behind that? And what do you mean by optimizing queries in their favor? This is starting to sound like a Net Neutrality debate.
You're worried that if there's a DNS trail to follow, anonymity will vanish? Unless you regularly engage in DNS spoofing to trick people into confusing your identity with someone else's, I think you're already screwed by virtue of the fact that everyone you communicate with has your IP address.
So what in hell does DNS have to do with personal accountability?
dn$$ec (Score:0)
DNSSEC (Score:2, Insightful)
Since Olaf been pretty heavily involved in the protocol development, he likely does think of it as a success or at least on the road to success. The reality is that it is getting some traction, but it is a long, steep hill.
What does DNSSEC buy you? It allows you to use a cryptographic check to assure yourself that the data you have is the same as the data the zone maintainer put into the zone. It's object security, rather than channel security, in other words, and it could turn out to be very useful. In particular, it could mean that you would have a way of trusting the data you get from peers, which opens up new scaling possibilities for authoritative data. It doesn't mean that yet, because the whole system mimics the DNS design of descent from a root zone, and ICANN won't sign the root zone. There are proposals, including DLV, for look-aside validation, but they don't provide the same level of security. Instead, you get to decide whether the look-aside validator is clever enough to have done the right checks without the business relationships that underly the real DNS chain of authority. Without ICANN signing the root, DNSSEC isn't really compelling, as it is bootstrapping security based on trust relationships that are vapor-solid. With it, it can be useful in setting up new distribution mechanisms for key data (if you could trust anyone to hand you the root zone while you had a valid way to check the signature, DDoS attacks on the root become very hard), and it helps against cache poisoning attacks. Since those are the precursor to other attacks (especially identity theft attacks), it is worth doing.
But sexy? No. In demand? So far, only by previous victims of the attacks, but that may change if the connections are more obvious.
"Chicken and egg problem"? (Score:1)
If DNSSEC Is Success, What Does Failure Look Like? (Score:4, Interesting)
Nothing about DNSSEC has improved since wrote about it last year [matasano.com]:
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.
Re:If DNSSEC Is Success, What Does Failure Look Li (Score:0)
Someone speaks the truth, who are these people who turn themselves into ruling class assholes and constantly pretend that they are working to make the world a better place.
The parent hits the nail exactly on the head.
And if we did want simple and more secure dns infrastructure, we would simply sign the root with gpg and encourage everyone to run a local root server whenever they run a cache.
Re:If DNSSEC Is Success, What Does Failure Look Li (Score:0)
So, while your points were pithily worded and certainly sounded insightful, your general argument suffers from a complete absence of facts.
Re:If DNSSEC Is Success, What Does Failure Look Li (Score:2)
Re:If DNSSEC Is Success, What Does Failure Look Li (Score:2)
Re:If DNSSEC Is Success, What Does Failure Look Li (Score:2)
Wouldn't that preview button been a handy thing to press? Sigh...
The current "standard" (RFC2535) remains "dead and buried" according to DNS pater familias Paul Vixie
I'm pretty sure that Paul knows about RFCs 4033-4035. I suspect you don't though.
Nobody even knows what problem DNSSEC is meant to solve, and why it's worth deploying in a world with pervasive TLS
Do you use TLS for every web page you visit? Do you use it for all the email you deliver? Receive? FTP sites you visit?
It's a nightmare to deploy, both for administrators and for software developers who have to handle things like precomputing tens of thousands of expensive signatures
Many tools do exist, as does hardware, to help with that process. I certainly do agree, though, that if you're trying to publish a large zone (say .com) on a very frequent basis (sub-hourly) you'll hit problems. That's always a problem with cryptographic solutions. (note: there is no requirement to pre-compute the signatures; you could compute them on the fly but that has other issues).
The only reference implementation of the protocol is BIND, the second-least-trusted piece of open source code on the Internet.
Look again.
How was this post not modded a troll?
WORKING DNSSEC spec needed and wasn't available (Score:3, Informative)
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].
I'm looking down the page, and see phish (Score:1)
You need secure connection? Build a custom browser. The browser checks the other end with its assymetric keys and maybe its one-time pads, and if the keys are wrong, it doesn't connect, tells the user to use something other than the 'net to contact the other guy.
No changing colors or showing lock images in the universal browser to show that the connectionis secure. Just make or break. The problem in general is letting the customer know, and getting the special purpose browser into the customers' hands. Physical banks can do that, but PayPal is going to have a weak point in the distribution. Physical mail could help, as could, perhaps, cooperation with financial institutions with a physical presence.
But the solution to dns poisoning, as some have noted, is to layer it on top of the current dns and IP infrastructure for those applications that need it. The lowest levels of communication have to be simple, and asymmetric keys are not that simple.
Oh, and one more thing. Centralized identity servers are an oxymoron, a conflict in requirements. No central office can know who an individual is, period. The current crop of peer-to-peer identity servers are a bit overdone, but the only good solution is peer-to-peer or local group. And separate identities for separate applications. Centralization removes the safety backup systems that work out-of-band. Gotta keep humans in the loop.
joudanzuki
Bad Logic. (Score:1)