Matasano Chargen - Latest Comments in A Case Against DNSSEC, Count 1: Solves A Non-Problem

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

creditcardquick.com — Fri, 10 Jul 2009 15:05:45 -0000

I like the way you tried explaining the concepts behind the issue. It makes readers want to scroll down and read word after word. However there were certain parts where it gets a little confusing but all in all it was good.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

fdask — Thu, 25 Sep 2008 09:53:04 -0000

Brilliant article! Your diagrams really make it.

The last point about BIND having many security flaws related to DNSSEC is an interesting one. I use tinydns myself, and was actually looking into DNSSEC after reading about irs.gov implementing it (Slashdot). Apparently tinydns does not support DNSSEC, nor is the author interested in it for a lot of the flaws in the system you pointed out.

"I'm not going to bother implementing DNSSEC until I see (1) a stable, sensible DNSSEC protocol and (2) a detailed, concrete, credible plan for central DNSSEC deployment. " - http://cr.yp.to/djbdns/forgery.html

A chicken and egg problem I guess! Anyways, kudos on the informative post.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Peter — Fri, 11 Jul 2008 11:05:20 -0000

@Chris Pepper

3a) If I’m really sneaky, I could grab the hostkeys, and tap port 22. If I have the hostkey, I should be able to eavesdrop on all communications either way by “following along at home” and replicating the host’s crypto calculations with its key.

I don't think so - can you also follow the Diffie-Hellman calc?

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

dot tilde dot — Thu, 12 Apr 2007 11:06:22 -0000

thomas, thank you for putting it together so nicely, all with the beautiful illustrations. great writing style. gotta show it to mom. shell love it.

.~.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek — Wed, 04 Apr 2007 20:13:10 -0000

Don't! I can use the opposition!

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Chris_B — Wed, 04 Apr 2007 20:02:29 -0000

my bad. "authentication" wasnt the word to use. should have gone for "authenticity" instead. Still chewing on this overall so may back down again or not.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek — Wed, 04 Apr 2007 15:07:58 -0000

I'm going to talk a bit about DLV and all the fun that that entails; I don't want to get too far ahead of myself, but, think, "ALTERNATE IANA/IETF FOR DNS".

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Shawn F — Wed, 04 Apr 2007 15:01:20 -0000

(sorry if this has already been discussed but I have not had a chance to read this post in detail)

For the paranoid among us I found this interesting:

http://www.theregister.co.uk/2007/04/03/dns_mas...

I wonder how much truth there is to in and if this is in anyway going to cause the US Gov to try and push DNSSEC forward.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Gustavo Bittencourt — Wed, 04 Apr 2007 12:52:06 -0000

Thomas

I agree with everything you wrote here. BTW, I love the illustrations too.

Regards

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek — Wed, 04 Apr 2007 01:08:20 -0000

DNS doesn't solve authentication problems for applications. All it does is bind names to IP addresses, or (in a better world), names to little bundles of opaque data.

And, as I hope my next 2 posts make an adequate case for, I mean "bad" in your first sense. "Really" bad.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Chris_B — Tue, 03 Apr 2007 23:58:46 -0000

"bad technology" in the sense that it will cause Godzilla like counter effects or in the sense that there is disagreement on what problem it is intended to solve exactly ?

But seriously. All hyperbole aside, I see your points but for reasons of practicality, I dont entirely agree with your assertion that authentication should be solved at a higher layer.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek — Tue, 03 Apr 2007 23:05:12 -0000

Well, OK, that's fine as far as it goes. But independent of how far technology can go to protect us, DNSSEC is bad technology.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Chris_B — Tue, 03 Apr 2007 23:02:20 -0000

TP

I think you finally hit the nail on the head. Protocols are generally not the answer because technology cant fix social problems on a large scale. This has been under my fingernails for a while now but I dont think the idea will be generally popular with anyone. The Internet isnt broken and cant be fixed. People are broken. The "fix" tends to come from social structures and laws (and law enforcement).

In any case its not SSL/TLS or the Verisign protection racket goons which secure your purchases from Amazon or your ebanking; its consumer protection laws which limit your liability for misuse of your credit card or protect you from bank fraud (in the US anyways, the rest of the world is different).

SSL/TLS/PGP/SSH are due dilligance practices. DNSSEC may or may not be in the future.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek — Tue, 03 Apr 2007 21:36:57 -0000

It's kind of hard for any protocol to help you if you lose your machine to an attacker. My point is, losing entire DNS servers to attackers seems to be the common failure mode for DNS security. Maybe protocols aren't the answer.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Chris Pepper — Tue, 03 Apr 2007 21:32:32 -0000

Thomas,

Yes, SSH warns you when keys change out from under you, but there are 3 major categories of threat here, and this protects you from the uncommon one.

1) If I subvert DNS and interpose my machine running sshd for yours, hostkeys will warn you. But I've never seen that happen (not that it doesn't, that it's uncommon).

2) If I break SSH (which used to happen all the time, but has definitely tapered off), I 0wn sshd, and grab its keys. You can't tell you're now talking to a compromised sshd.

3) If I break into the host OS any other way and get root, I can "upgrade" to my own compromised sshd binary and keep the old keys. We upgrade sshd all the time, retaining keys. No help from hostkeys here.

3a) If I'm really sneaky, I could grab the hostkeys, and tap port 22. If I have the hostkey, I should be able to eavesdrop on all communications either way by "following along at home" and replicating the host's crypto calculations with its key.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Dave G. — Tue, 03 Apr 2007 20:43:16 -0000

What Tom forgot to mention is that the jar is labeled "Donations for DNSSEC"

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek — Tue, 03 Apr 2007 20:21:22 -0000

Edited this post because I'm removing a word from my vocabulary.

(Yeah, right. But Dave is going to make me put a dollar in a jar every time I say it!)

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek — Tue, 03 Apr 2007 18:24:00 -0000

Chris, I'm going to challenge that: I don't verify hostkeys, but I *DO* notice when I suddenly get prompted to accept a new one. SSH does a pretty good job of being loud about this.

We're pretty paranoid about this, so maybe we're not representative.

Of course, in the current state of the art, key verification finds its asymptote at browser cert verification, which end-users completely ignore. The same security problem you point out for SSH ALSO occurs if you click through the browser warning. When you discuss getting any better than browser cert verification, you are talking about making SSL/TLS more attractive, and thus (by my reasoning) making DNSSEC LESS attractive.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek — Tue, 03 Apr 2007 18:22:02 -0000

Trevor has lucidly stated probably the most common case I see made for DNSSEC, which is that once you have DNSSEC, you can build other security applications on top of it. DKIM seems like an example of a practical proposal like this.

Trevor is totally, 100% correct.

I simply propose then that we evaluate the -SEC seperately from the DNS-: create a totally seperate hierarchy, run the protocol on different ports, get it the hell out of BIND, and use it solely as a building block. But leave the DNS hostname resolution system alone, because it works well enough now.

Trevor, I have 3 more detailed posts coming on this, and I'd love to see if the rest of my arguments influence you. =)

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Chris Pepper — Tue, 03 Apr 2007 17:42:56 -0000

Nice explanation. Unfortunately ssh isn't really that secure. In at leaset 90% of cases, initial ssh connection goes through on the blind assumption that the server isn't already cracked. I've never seen someone actually verify a hostkey (although you can do it through DNS, which is good for organizations more paranoid or organized than us).

Also, the DNS MitM protection assumes that people are somewhere on the Internet, and can subvert DNS, but cannot subvert sshd or the server OS, in which case they can steal the unencrypted hostkeys and impersonate all they want, or simply eavesdrop without affecting the client-server communicatons at all.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Ryan Russell — Tue, 03 Apr 2007 17:13:02 -0000

Well, I'm not going to discount your position based only on the number of DNS servers vs. keys running around, that's what I was poking fun at.

I really would like to see secure name resolution, I don't see any good reason for that problem to not be solved eventually.

I know basically nothing about DNSSEC, so I'm happy to take your word for it that it's a mess. I don't know much about IPSEC either, but it didn't take me long as a VPN administrator to not like it.

I also have little faith that a big standards committee is going to come up with the "right" solution. So, I can't lobby that the IETF whatever needs to try again. It's like thinking there should be a law, and not trusting the lawmakers to get it right. That's why a lot of people are afraid of Net Neutrality.

And finally, I'd have to agree in many ways that this isn't the highest priority in the security world. I didn't know there was a limit to the number of efforts, I thought they kind of went in parallel. But yes, there's a limit on our ability to consume new standards.

So I don't have any good basis for arguing with you. Sorry.

Next time, though.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

trevp — Tue, 03 Apr 2007 17:02:50 -0000

Hi Tom,

I think you overlook one potential use of a secure DNS. You say -

"Securing the DNS protects DNS lookups. But Alice and Bob still need another layer of security."

You mention that web-of-trust (PGP), CAs (PKI), or key continuity (SSH) all can bootstrap this other layer of security.

But so could a secure DNS! Consider the potential for putting, say, key fingerprints in DNS to authenticate MTAs and webservers. Or policy information indicating "all emails from this domain are signed".

I think your argument against this would be that key-management external to DNS is superior due to the end-to-end argument - it's better to have specialized third parties "whose only job is to protect cryptographic secrets" than to burden DNS with this.

However, when you really look at it, whether the function of providing authenticated (domain-name, public-key) mappings is best provided in DNS or by external 3rd parties is not immediately clear.

For example, how are these third-parties going to check that someone really is the correct owner of "example.com" before issuing them a certificate? By checking with the domain name infrastructure? In that case, the domain name infrastructure already is the authoritative source for this information, and already has the capability of delivering it efficiently to requestors. So introducing 3rd-party CAs is introducing an additional point of control, security risk, and protocol complexity, and it's not clear that the gains of, say, more centralized private-key security, compensate for that.

Anyways, certainly CAs can be useful in certifying attributes besides domain-name - e.g., "the holder of this key is a trusted financial institution" or somesuch. And it may be that these other bindings are more important than (domain-name, public-key) bindings.

However, if authenticated (domain-name, public-key) bindings do have value (and I think they do), then it would seem to me that a secure DNS is a fairly elegant way of providing this. (though I'm not familiar with DNSSEC enough to know whether it's the best way to provide this).

My 2c, anyways... Cheers.

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek — Tue, 03 Apr 2007 15:06:16 -0000

That's too bad. I was kind of hoping that you were. I don't think I'll keep the smart IETF type's attention, and the dumb ones are just going to say, "well, how many RFCs have YOU written?"

Somebody devil's advocate!

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Ryan Russell — Tue, 03 Apr 2007 15:00:25 -0000

Private key auth, then? Yes, I would agree there are more DNS server than that. I don't know if that supports your point as well, though. ;) You know I'm just poking at you for fun's sake, and not as an actual argument against your thesis, right?

Re: A Case Against DNSSEC, Count 1: Solves A Non-Problem

Thomas Ptacek — Tue, 03 Apr 2007 14:45:47 -0000

BTW, Ryan, I said SSH keys, meaning to imply, "people who have gone through the trouble of generating, encrypting, and saving their own personal SSH keys". The numbers may work out better that way.