Root DNS Zone Now DNSSEC Signed
isc.org
isc.org
Did you know that they designed DNSSEC in a way that makes it difficult to not dump all your hostnames to the public, 'host -l' style? In order to provide a non-repudiable "no such host" message, they made DNS zones walkable. When people freaked out about that (justifiably so!), they modified the protocol so that names are hashed, password-file-style --- and are password-file-style crackable.
Did you know that because almost every piece of software that does name lookups uses "gethostbyname()", which provides no error channel, DNSSEC can't even give you a scary popup when a key expires or something is misconfigured? That unlike SSL --- which causes millions of such popups every day --- DNSSEC basically implies that either everything's configured 100% perfect or... that host doesn't exist?
Did you know that SSL/HTTPS in no way relies on a secure DNS today? That all that certificate signature stuff that people complain about boils down to a system designed to work even if the DNS is totally hostile and owned by attackers? And that the system has been attacked and refined and basically solid for something like 15 years?
Did you check out Dan Bernstein's presentation about using DNSSEC as a denial-of-service amplifier? I leave it as an exercise for you to find out how many megabytes of traffic you can get DNS servers to hurl at Twitter in response to just a few packets of your own.
DNSSEC is a debacle. It's been scrapped and redesigned (I believe) three times now, from the days in the 90s when it was a government project to the "whitelies" and "NSEC3" scramble that happened just a few years ago when they tried to deploy the "everyone gets a list of everyone else's hosts" design.
What's worse, we don't need it. DNS has been insecure for over 15 years, and DNS is not a primary attack vector on the Internet. When DNS is part of a malware attack, more often than not it's because the malware has reconfigured the victim host, which DNSSEC can't do anything about.
What's worse than that is that the bit we really could stand to address --- the insecure connections between end user computers and DNS servers --- could have been secured at far less cost and drama than the cache-to-authority problem the DNSSEC group bit off. But wasn't.
There seems to be some momentum behind finally getting DNSSEC deployed. I think it's actually bad for the Internet; that it will cause reliability problems, create a huge amount of work for server admins, not solve any real-world security problem, and create a false sense of security. But be that as it may, it appears to be coming.
Just make sure nobody gets your credit card for any kind of DNSSEC-y service. That's, I guess, my advice.
That said, one thing I believe you're wrong on is gethostbyname() which does have an error channel via h_errno. It's not pretty and more things need to be defined to correctly handle DNSSEC issues, but there is something there. I agree though, that we're unlikely to find a good transparent way to have this work right with old applications and that's a killer.
I don't share your enthusiasm about SSL/TLS fixing this problem. SSL/TLS has its own issues...
Also, what do you do when h_errno says something is tainted? First, you need to distinguish between transient and permanent failures. Now you need UI for both. Which means you've added another state machine hop in your program in every place you look up names (note that most network programs, even when they're async, don't bother to design host lookup asynchronously) --- what was one function call is now three functions, everywhere you look up names.
Anyone who uses curl to do stuff on the web probably knows the flag to turn cert checking off. Curl and wget are somewhat unique in needing to care about validation. Observe that now every single program that does anything with the network, from "ping" through "ftp", now needs a flag and a sensible default for how to handle broken names.
Yeah, this just isn't going to work.
There used to be herror() but it appears to have been deprecated. An central error checking function in the standard library wouldn't be a terrible addition. Handling GUI stuff sensibly is going to be an even larger nightmare, but at least frameworks like Cocoa and Qt should be able to help do this right. There's a large bridge right now for GUI error reporting that should be handled more gracefully in a lot of cases, not just for DNSSEC, frameworks need a graphical perror() in general.
In any case, DNSSEC certainly makes this all a bit more trouble.
a) SSL is worth jack shit. It only tells me that some person paid some obscenely large sum of money to some company so that my address bar glows in green. CAs do a very bad job at verifying their customers. There have been valid certificates at pishing sites and valid certificates with fake data.
DNSSEC wont't fix that. But it will guarantee that when I type bankofamerica.com in my browser, I will land at bankofamerica.com, even if someone tries to hijack me.
b) We do need DNSSEC. Please go and watch Dan Kaminsky's talk about the ramifications of the DNS bug he publicized. Everything in the end falls back to DNS. Want a SSL cert? You will receive it per mail. Guess how the CAs mail server will find your company's mail server...
c) Please don't start with "secure the connection" instead of "secure the data". Even if I know that the line between my computer and my DNS server is secure, I can't trust my DNS server.
I agree here, except I think you meant to say that SSL certs are worth jack. And that's entirely true, as far as I know. SSL the protocol is probably more or less ok.
I disagree with you in that I don't trust the competence of the designers of DNSSEC. We may need something similar, but I doubt that DNSSEC as it exists today is it.
Your comment overall makes very little sense. The problem you're alluding to --- the one that means "SSL is worth jack shit" --- is a user interface problem. It's a serious one, but not only does it not go away in a DNSSEC world, it actually gets far worse.
DNSSEC isn't a magic bullet that solves the logistical problems of verifying Internet identities. The market has been beating the crap out of mutual authentication for financial websites for over 15 years. The company with a real solution to that problem will make billions of dollars. DNSSEC isn't that; it's a bunch of guys on a mailing list arguing about the one piece of the stack that they've chosen to fixate on --- and the surprisingly bad solution that resulted from the process.
This isn't just my opinion, by the way. Read every working group post (like I did) and watch Vixie's tone as the protocol evolves from what TIS came up with to where it is now, when he starts saying, in effect, "anything, anything, let's just get something deployed!"
That's really too bad. It should. DNSSEC can handle providing CERTS. Using these CERTS and DNSSEC to validate them (on top of the rest of SSL/TLS) would be a secure and free way for domain owners to provide a better security than provided by SSL/TLS as implemented today.
SSL/TLS requests can be man-in-the-middled by any one with access to any of the 150 or so root keys in your browser including for example the governments of Taiwan and China. If we used CERT DNS records, then not only would we not have to pay additional money to VeriSign etc to have a CERT, but there would only be twoish keys that would allow man-in-the-middle attacks (the root DNS zone and the .com DNS zone for example). That is a significant improvement.
Does anyone know if any of the browsers have plans to provide DNS CERT support?
As for the "150 root keys" issue: that is in fact a very good point. Remove the sketchy ones from your browser. Someone should publish a list --- "these ones are probably fine for people in the US to remove". Whoah. Look. I just solved that problem in 15 seconds, using the Firefox UI; it didn't even require an IETF working group to discuss it!
;)
2. NSEC3 doesn't allow zone walking. DNSSEC entirely gives you the option as to whether or not to allow zone walking.
3. That is not an artifact of DNSSEC, that is an artifact of the fact software vendors haven't come to consensus on an approach on richening their DNS APIs. Arguably this is a chicken and the egg problem, which is why many have felt it was more important to get zones signed and then software vendors can come to a an improved approved they can test against deployed zones.
4. Many believe DNSSEC will enable SSL to move to a model where certificates are published in the DNS, rather than blessed by third party CAs. Imagine self publishing certificates in the DNS for free rather than paying for costly validation by a company like VeriSign? Once the DNS is secure it provides the same level of trust that SSL vendors provide (i.e. that the domain is registered to you)
But the great thing is, if you don't like DNSSEC, you don't have to use it. End of story. It was designed to allow the DNS to run as-is if you decide not to turn it on.
2. You need to acquaint yourself with Dan Bernstein's presentation on NSEC3, but I think we can trust each other that we're not simply making things up. Like I said, NSEC3 --- the solution to zones being OVERTLY walkable --- creates a crackable "zone password file" that everyone can download.
3. The lack of UI for dealing with DNS failure is an artifact of the fact that the DNS was never meant to be secure, and so trying to layer an incredibly complicated security service model on it is a bad idea. Saying "that's up to the vendors to agree on" is, like the "sufficiently optimizing compiler", the very definition of hand-waving.
4. Those people who think that SSL CA's can be replaced by a vending machine built into the DNS are --- excuse the hyperbolic tone --- delusional. This suggestion not only doesn't solve the problem of how crappy vetting is for certificates, but actively amplifies it.
5. Wrong. If you are (for instance) a YC networking startup, you are going to pay through the nose in admin BS to deal with the hassles and failures created by this system which will cost billions of dollars across the board to deploy and which won't solve problems.
This is roughly what you'd expect from a workgroup led in part by people who's zones consist of machines like "old-1994-dec-alpha.state.school.edu" and "ultra-5-with-sentimental-value.math.state.edu". The impedance mismatch between this kind of person and the people who maintain "backend1.staging4.apac.bank.com" appears to be part of the reason that DNSSEC is such a debacle.
I'm not saying you have to go running off and caring about DNSSEC now, but the kneejerk "omg it's not deployed" argument really isn't helpful or insightful attached to a story about how it just finished getting deployed for real on the roots finally after years of waiting.
EDIT:
It goes without saying but I'll state it anyway, this cascade of down-votes is not the reaction I'd expect for making what I consider to be a pretty innocuous comment about something that potentially affects the priorities of my startup.
It goes without saying but I'll state it anyway, this
cascade of down-votes is not the reaction I'd expect for
making what I consider to be a pretty innocuous comment
about something that potentially affects the priorities of
my startup
If you insist on not caring, do so quietly. Some people around here are trying to fix things, or break them, which hopefully will result in better systems. In any case, you appear to be doing neither.
(As a side note, your assertion that I agree that this doesn't change anything practical is false, as of yesterday people can resolve domains over DNSSEC, that wasn't true last week. I consider this a practical change. I'm not a big fan of DNSSEC as a protocol, but this is a big deal(tm).)
People can resolve the root over DNSSEC. This is a milestone, but it's one to be followed by many, many more before it affects clients.
isc.org appears to be using it already, for instance.
Edit:
$ whois isc.org | grep DNSSEC
DNSSEC:SignedI do not dispute that some people are able to use DNSSEC and this does not belie my original comment.
Today: Many people can use DNSSEC. Some actually are. Some clients are affected. (Just obviously not yours, since you remain completely uncaring about the subject.)
I don't see how it could be any clearer.
You are quite right that my clients are unaffected. I like most of the world run a mix of Windows and OS X which like the software that runs on top of them, are not DNSSEC aware (with few exceptions).
Clearly I do care about the subject and I'm not sure why you keep stating that I do not. There is a difference between ignoring a technology until it's useful and ignoring it full-stop.
EDIT: Edited for brevity.
People want a story about how the Internet is getting a cool new security capability.
They especially want that story to come at the expense of Verisign and the SSL CA's.
Expect downvotes.