DNSSEC: Good Enough?

Phil Windley writes "DNS Security Extension, or DNSSEC, is a set of extensions to DNS, which provide end-to-end authenticity and integrity. Paul Mockapetris, the inventor of DNS believes DNSSEC is the answer to many of the identity problems on the Internet. He wants the IETF to get off the dime and approve the DNSSEC spec. A recent article in ZDNet TechUpdate interviews Mockapertis on DNSSEC (summary)."

Comments

Costs

[$exyNerdie]

A lot of research and ideas and papers have been thrown around to replace SMTP with a better protocol but the costs involved are a major discouraging factor and people don't want to install a system when there is no guarantee that all the recipients have it too.

Maybe servers using a new mail protocol should be designed such that they first attempt to use the new protocol and if connect fails, try the good old SMTP

A simple as hell answer.

[Anonymous Coward]

Do not send the message along with the envelope. Mail servers should only collect message envelopes, which contain information to obtain the real message. Then when someone reads their email their email program contacts the server to obtain the message. Thus you can't send email and vanish, since if you're not there when someone checks their email, they won't get your message.

Obviously ISPs will have to have the ability to store the messages of their users so they can deliver them while the user is offline, but that's no problem. If a user, or someone else, sends spam, once the ISP is notified, they can remove it from their servers, so that no further people who were sent the spam will actually recieve it upon reading their email.

Why I'm writing this I don't know. No one reads below score 3 anyway unless you're lucky and get one of the first 10 replies. Slashdot is useless. I'd shit myself if one person actually read this post. Hell, I can't even find posts after I make them, even after waiting several hours.

Design vs. Implementation

[SlashCrunchPop]

Protocol design and implementation are two very different things, as anyone who has ever configured and used BIND knows from personal experience filled with agony over buffer overflows from hell. I hope that DNSSEC code will be written at the level of quality of djdns.

Yes, Dan Bernstein is a very exasperating person and his code is hideously formatted, but it is effective, efficient and among the most secure code ever written. I still hate him though.

Then there's Bernstein

[crucini]

Of course, no discussion of DNSSEC would be complete without Bernstein's comments. And here are the slides from his talk in pdf.

Not being an expert on the topic, I find DNSSEC a little worrying, as it seems to be a consolidation of the centralized power of Verisign or whatever. Ideally we should be planning how to move away from traditional DNS altogether, as the single-rooted namespace has led to much political abuse. But that is a really hard problem to solve.

First, solve this ...

[Anonymous Coward]

Quoth the article:

"The technology behind these confidence
checks uses digital signatures and
public key cryptography..."

First, find a way that I can get a "top level" CA to give me a certificate without charging me $US350 _per year_

DNSSEC?

[AltGrendel]

Wouldn't working on a improved form of SMTP be a better project?

Re:dan bernstein's position on this

[macshit]

djb's points about dnssec seem reasonable, but his proposed solution `nym' seems quite nutty.

He basically proposes only allowing a form of hostname which is (1) too long to type manually, and (2) includes long random-looking strings. His justification for this is `users seem to do alright with bookmarks, and as soon as everything is links, no problem!'

Is he living on the same earth we do? It's going to be a long time before manually enterable -- and verifiable -- hostnames become redundant (if they ever do).

Why?

[Anonymous Coward]

Why would you want to authenticate DNS traffic? I'm sure there is a perfectly good reason, it just isn't immediately apparent to me.

Trusted computing...

[Ryan Broomfield]

Trusted computing means seperating hosts into two piles: trust and non-trusted. What rules apply to gaining "trust"? Is gaining "trust" a monetary decision? How does the little guy make sure that his content is seen without paying for a costly, restrictive license? Would he have to constantly censor what content he has with his host in order to maintain a "trust" certificate? Seems more like censorship than protection to me :\ This is only my opinion, of course.

DNSSEC needn't be a panacea to be useful.

[mellon]

DNSSEC provides a secure key distribution mechanism. Right now, the only secure key distribution mechanism on the Internet is the SSL key mechanism, whereby a cartel of ~5 companies with keys that got into the original Netscape release essentially rule the roost, because Joe Average has no idea how to install a new root key in his browser. The cheapest key of this type will cost you ~$150 per year, and you can't use it to make more keys.

DNSSEC does require a top-level root key, but once you have registered your domain securely, you can generate keys whose public halves are *in the DNS* where anybody can get at them. That is, you can use your key to make more keys. Also, if you don't want to do business with one registrar, you can go to another, and as you are no doubt aware, the DNS registration market is quite competitive. So in fact DNSSEC is very democratic compared to its only current alternative.

Unfortunately, this is not a glitzy thing. This is nuts and bolts, wire dragged through conduits. DNSSEC is a really nice platform for building a more secure internet, but it doesn't solve the problem on its own - you have to build on it - e.g., using it to make SMTP more verifiable.

DJB says that BIND doesn't do DNSSEC very well. It's true that BIND 8 doesn't do as well as BIND 9. If you want to spend some money, my employer will sell you something even nicer. But the fact is that there are several free, working implementations of DNSSEC out there right now.

BTW, in the interests of full disclosure, I should say that I work for the same company as Paul Mockapetris (Nominum), and have in the past worked for the company that DJB styles "the BIND company," although I know much more about DHCP than about DNS.

Let's see PGP applied here

[Anonymous Coward]

Let's say the Slashdot guys create a PGP key, publish the public key on the various keyservers, and start signing their web pages. Once I have a path from my key to theirs, I can be pretty sure that it's really them.

Even if I don't have a path, my future browser could record the key that's used when bookmarking a site. That way if I come back to it later and the key doesn't check out or another key has been used, then I know it's been compromised since then.

This could be used for other purposes. Let's say someone has a personal web page somewhere and is forced to move for some reason. You could be sure that it's the same person at the new URL because the same key would be used to sign the content. The best part is that whoever takes over the old URL can't spoof the old guy since they don't have his private key. All they can do is publish the exact data he already had out there.

Taken to an extreme, you could almost stop caring about URLs. You could look up someone by searching for their PGP key, and then work out from there. It wouldn't matter where they were actually hosted, since it is verifiably them. There would be no point in publishing phony information, since the key wouldn't check out.

DNS let us abstract away IP addresses to some degree. URLs can get us away from worrying about specific hostnames. Can this be the thing to abstract URLs away to some degree?

Political Problems with DNSSEC

[billstewart]

Some of the problems with DNSSEC are technical - most of them have to do with making things fit inside 512-byte packets and not breaking too many server implementations. But the big problems have been political, including politics implied by the protocol structure and politics that's separate from it.

• Old US Fed Attempts to Stifle Crypto - Back in 1993, when DNSSEC was drafted, the US government was still doing the Cold War thing of pretending that there were Commies who shouldn't be allowed to have Crypto because their Spies could send Unbreakable Messages, and the FBI was encouraging them to maintain this charade because crypto might make illegal wiretapping difficult and mass wiretapping expensive. So Open Source publishing of DNSSEC code on the Internet or export to other countries was threatened by all the rest of the anti-crypto Export Law stuff, even though it only needed digital signatures and not encryption - because RSA digital signature code is also usable as encryption code, and because good digital signatures make forgery impossible. At one point, John Gilmore got approval for exporting a "bones" version of DNSSEC (with the crypto code removed) and then the approval got yanked shortly afterwards, in spite of their being no adequate legal justification for it. DNSSEC was pretty much stillborn because of those politics, which was too bad because we could have had a DNSSEC in place when the Web thing was taking off.
• Hierarchical Nature of DNS - For many security and political applications, a hierarchy is a Bad Thing, because it means that somebody's in charge, and that there's one big weak point to attack it with. That doesn't seem to be much of a problem for DNSSEC, because it's piggybacking on DNS, which is inherently hierarchical. Sure, there's all that ugly politics about who gets to sell the name example.com and who gets to resolve conflicts if multiple companies want to be the One True Owner of the domain name example.com, but getting the folks who manage official assignment of the name example.com to sign the DNS record is a simple technical implementation, just as getting them to put the IP address in the DNS server is - it's *much* simpler than getting them to send the bill or the renewal notice correctly.
• ICANN Ugliness - Of course, all this was mired in political ugliness, and the ICANN Name Gods fundamentally weren't interested in doing the right thing technically - they were interested in doing the power-grab thing on the intellectual property trademark space, not in technical administration. And the people who fight about name space ownership and collect your registrar money aren't really the people who run the physical root and .com DNS servers, many of whom worked for organizations funded by the US Government, who weren't going to push for crypto protection.
• Multiple Name Registrars, Single Keys - There's a big ugly gap in the DNS hierarchicalness, which is that multiple registrars can sell you the name example.com, but there's only one DNS Signature Key for .com - does that mean that 50 random companies around the world can all be trusted to own those keys and not leak them? Fat chance! But the protocol wasn't designed for that kind of sharing.
• One Root To Rule Them All, again - If there's only one Root, and they don't get it to buy in to the plan, which they didn't, and it doesn't sign the keys for com, edu, etc., or the country codes, then there's no clean way to bootstrap the system. Sure, there were all the alternate-root guys trying to compete, and any country-code TLD administrator (e.g. Tonga's .to) could have created a key for their TLD and started signing keys, but without The One True root key, eventually it falls apart. Tonga or Norway or someone could declare themselves to be the head of the Cabal, issue a Root Key, sign other TLD's domain name with it, and start selling more DNS names to people who wanted them, and

dnssec, how about authenticated email reply-to?

[tjstork]

Someone at 130.160.91.27 evidently is spamming people with my email address as the reply to. While they are working on dnssec, perhaps someone could modify SMTP / POP servers to validate the reply-to domain or disallow the mail.

Re:dnssec, how about authenticated email reply-to?

[Anonymous Coward]

Try publishing SPF data in your zone(s) and hope the rest of the world starts using it. If that happens, your forgeries should go way down, since they'll be coming from systems that are not authorized to send mail as your domain.

Note: I set this up on my domain about two weeks ago, and a fair amount of mail goes out from here to various mailing list subscribers. So far I haven't logged so much as one query for the SPF data. It's still very much in larval stage.

Re:DNSSEC and extending protocols

[MrChuck]

SMTP has (and should have) no way to do end to end encryption of a message. It shouldn't. It's transport, not data.

SMIME is a fine and lovely and centralizable way to do mail body encryption.
SMTP/TLS is a fine way to do transport encryption/authenication from one hop to another.

Lacking is a way - perhaps a signature header - for an MTA to "know" where a message is from. I'd love to be able to prioritize mail that's perhaps from "known good" domains. I believe IronPort is doing something proprietary along these lines.

Back to DNS:
DNSSEC tries to offer a way to ensure the content of a zone.

It's a good notion.

It's not been implemented well. I don't trust VeriSign, I certainly don't trust JoeBlow registrar. However, I'm willing to trust my domain and that's really what's needed when dealing with subdomains. And most of the meat of my DNS use is in the subdomains - every desktop, every server lives in a subdomain. www, ftp and MX records are in the top level - that's about it.

With BIND 9, I'm delighted that all my zones use notification and IXFR's (tranferring a 40,000 record zone over a DSL is not good without incremental zone transfers - esp in a DHCP heavy environment that can cause regular zone updates).

We can "extend" DNS with DNSSEC (or -alikes) because it's negotiable (like ESMTP is for SMTP). We cannot change how ALL DNS transfers and works by default without GREAT pain (we did that pain ONCE in 1980 going from NCP to TCP).

Decentralized authentication

[Tyler Close]

Since you're willing to give Bernstein's solution a fair hearing, I suggest you also check out YURLs. There's even a simple proof-of-concept WWW browser that you can use to get a feel for how the WWW without DNS works.

Note that switching to decentralized authentication doesn't mean giving up on human memorable names, just global human memorable names. Users can still use a local namespace. This provides both useability and security benefits. See the YURL Name paper.

Tyler

Consistency, not True Name Identification

[billstewart]

DNSSEC means that if somebody sends you IP packets at anonymous-coward-43.com, they can be cryptographically certain that they are using the IP address that the owner of anonymous-coward-6.com currently wants to advertise. Nobody had to mess with True Names here - this isn't solving the problem of verifying that Anonymous-coward-6.com belongs to John Smithy, who's the heavy guy with the slightly greying beard and the name anonymous-coward-43 tattooed on his arm who lives at 1500 Pennsylvania Ave and has Amex number 8811-432612-990433. This just means that when the Name Gods issue you the domain name anonymous-coward-43.com, you give them the admin key for the DNS as well as the money.

It's unfortunate that the ICANN Gods want to require everybody in the world who sells domain names to get a True Name and Subpoena Address and ICBM address and Retina Print in Triplicate in return for letting you use the name, but you knew that when you got the name. And if you're using a subdomain Number-6.anonymous-cowards.com, and the people who run anonymous-cowards.com will let anybody get a subdomain name without providing all that personal data, you're still protected - you've got a cert that anybody who wants your IP address can use to verify that it's really yours and not some proxy server at fbi.gov.

DNSSEC seems awful overblown

[Jordy]

Maybe I'm missing something, but DNSSEC seems to go a bit overboard when trying to fix the major flaw in DNS today, the ability to falsify records.

Now, there are two ways to falsify records that I know of.

The first is a cross-zone caching issue where a DNS response contains records for a zone it doesn't control. This is a rather simple problem to fix and requires no changes to the protocol bitstream itself (though changes are required to how the protocol is handled). It basically involves applying a trust zone model and tossing some previously useful records.

The second is an ID prediction attack where a response to a DNS query is falsified by guessing the ID number of the query made by the DNS server. With a decent ID generator, this becomes difficult and you have to brute force the thing basically making it a one-in-a-billion chance. This is still too high, so modifications to the protocol bitstream are required to enhance the size of the ID field or add a secondary one. It is possible to hack in this with minimal compatibility problems, but it wouldn't be pretty. Alternatively having the DNS server simply query twice or use TCP would accomplish the same thing, though that slows things down a bit.

I fail to see how the leap to a full blown cryptographic PKI was made. Sure, technically it may be better, but it is also complex, intrusive and adds only slightly more security.

Personally, I'm happier with 99.999% security with minimal work vs. 99.99999% security with a complete overhaul of the system.

Maybe I'm missing something.

Re:dan bernstein's position on this

[the_olo]

How many of you use google to lookup resources these days? I find it much more convenient to look through a website using google to search on specific terms. Your answer shows lack of insight into the situation.

Then why use DNS at all? It's a service which has only one aim: to substitute IP addresses hard to remember by humans with something more memorizable (Well, you can say "Round-robin DNS records for providing clusters", but there are better ways for providing redundance).

DJB's proposed solution is worse than getting rid of DNS and using v4 or even v6 IP's in yperlinks and bookmarks.

Surely http://66.35.250.150 is better than, say, http://weoir123623tt23u4tgd2uwmnfskmhrlwhrjkqshfwh riwwyhwpurhuihrkjwehwhfh237wuhr4r272.slashdot.org?

The fact is, when I want to go to slashdot.org, openoffice.org or mozilla.org I type them into location bar (and the browser usually autocompletes them from history if I were working on that machine before).

Re:dan bernstein's position on this

[ansible]

I've never tried his DNS implementation, but I've heard it works nicely.

It does work nicely. Been using it for about 3 years now. No problems at all. After you get used to the DJB way of doing things, it is very simple to configure. The main data file makes more sense to me than BIND's stuff ever did.

But DJB is out there. One of these days, in my copious free time, I'll have to re-implement some of his better ideas, so that they can be released under a normal F/OSS license.

But I'm not using Qmail any more. Hasn't been updated in years, and to get needed features, it is patch hell. Switched to Courier MTA because I needed mail filtering, webmail and IMAP. I still like Maildirs though. Never had a problem with mailbox corruption or lost messages since we switched to that.