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

Check out Internet Mail 2000

[Bryan Ischo]

D. J. Bernstein, the author of the supremely reliable and secure qmail mail server, wrote a proposal for a new Internet mail system a couple of years ago. It's called Internet Mail 2000. Check it out at:

http://cr.yp.to/im2000.html

The basic premise is this:

"IM2000 is a project to design a new Internet mail infrastructure around the following concept: Mail storage is the sender's responsibility."

It's an interesting concept and worth a read.

Unfortunately it doesn't look like it would do much to stop spamming, which is the major problem with the current internet mail infrastructure. For that, we need some way to make sending bulk email costly to spammers. Actually I'd say that this could be done already with current technologies, it's just that ISPs and large network providers are not being responsible in ensuring that the users of their networks pay the appropriate price for sending out SPAM.

Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email ...

Re:Check out Internet Mail 2000

[letxa2000]

Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email ...

I wish people would stop inviting rate increases or new charges as an answer to spam. It's not the answer. It might be inexpensive for you, but many of us DO send a lot of email and it'd get expensive really quick. You'd get rid of a lot of good and valid email communication along with the spam.

I'm even opposed to the "pay a dime, but I'll give it back if I wanted to hear from you" approach. Those of us running a mailing list would run the risk of having some idiot sign-up a bunch of accounts only to have that person say "No, I didn't want that" and collect the money.

I believe we need a trusted protocol. This might be as simple as having all emails PGP signed and everything else being sent to the bit-bucket (if you want to be aggressive) or only passed through to the user if the unsigned message had an extremely low spam score.

But if everyone were to use Bayesian I swear we wouldn't even have to propose a new protocol, talk about new legislation, etc.

*SIGH*

New Protocol Name

[liam193]

This sounds like a great idea. Let's present a new protocol. I suggest we name it Slashdot Mail Transfer Protocol. We could use the shortened form SMTP. hmmm well... on second thought maybe the name needs more work.

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

slashdot

[Anonymous Coward]

is it possible for the Slashdot collective to come up with another one?

Not a chance. The slashdot collective taken as a whole, is a very stupid group of people. Even the few intelligent people wouldn't be able to get anything useful done because they'd be shouted down by the teaming masses of idiots.

We hate Sony's recording arm, but we'll sell our souls to them for the next cool gadget. We hate MS, but 90% of us use windows on our main home machine. No to mention all the idiots who use words like boxen.

well... ok...

[Ninja Master Gara]

As long as SMTP continues to the be the friendly protocol.

HELO imamailserver.com
250 Hello imamailserver.com [127.0.0.1] nice to meet you!

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.

dan bernstein's position on this

[tmu]

People interested in this issue should see dan bernstein's position on the issue of DNSSEC.

The summary: It's unfinished, the BIND company has poor implementations (like most everything else it implements), and won't provide a real increase in security. Interesting stuff.

DNSSEC: Good Enough?

[Anonymous Coward]

Nothing is ever good enough for /. readers, well except for Ogg Vorbis.

Ripe Training For DNSSEC

[thriemus]

It seems RIPE have a One Day Introduction Course for "DNSSEC and related tools, and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zone"

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:Security Issues?

[mellon]

I don't understand the security issues here? I tried reading the FAQ but I'm a mumbling nincompoop. Can someone explain in a bit better detail about why we needsecurity for DNS? Is there any actual recorded instances of people breaking into the DNS database? Is this the website hacking I've heard about?

DNS is mostly a UDP-based protocol, and it's pretty easy to spoof. When you type "www.ibm.com" in your browser, a UDP packet goes from your computer to a caching name server at your ISP (I'm oversimplifying here, BTW, but if you aren't a DNS geek this is most likely exactly what happens). The resolving name server sends another UDP packet out to the root name server to find out who to ask about "ibm.com". Then the root name server says "go talk to ibmns1.ibm.com at 10.1.17.2". Then the caching name server talks to 10.1.17.2 and asks it to resolve "www.ibm.com". Then it sends a UDP packet back to your computer telling it the IP address for www.ibm.com.

Notice that all of these UDP packets went over the network in the clear, and you can see that there were quite a number of opportunities to spoof you. If I can do a root hack on the machine that's running your ISP's caching name server, for example, I can give you a bogus IP address for www.ibm.com, and then steal your credit card info when you try to buy something there. If I can watch your packets and respond faster than the caching name server does, I can also convince you to go to the wrong place. So it's not an insignificant vulnerability.

With HTTP, if you are smart, you check to make sure that your web browser is doing a secure transaction, but frankly, most people just ignore this issue, or don't even know what it means.

With DNSSEC, your resolver on your computer knows the public half of the root DNSSEC key. So it can verify the answer it gets, all the way from the top down to the bottom. If someone spoofs the response, the resolver ignores the spoofed packet, and you get the real one. If your ISP's caching name server is compromised, you can't look up www.ibm.com, and eventually you call your ISP and complain. They fix their nameserver, and you go back to your business, unspoofed.

As I said in a previous comment, DNSSEC is also a handy place to stash keys, precisely because you can validate them as I've described.

And, BTW, I glossed over a lot of details here. If you really want to know how this stuff works, you should probably read the RFCs... :'}

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