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_

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).

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

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).