The DNSSEC Chicken & Egg Challenge

wiredmikey writes "To begin DNSSEC implementation or not: that is the question facing a host of enterprises, notably any that engage in e-commerce or online financial transactions (online retailers, banks, investment firms, hospitality and travel, etc.). These businesses find themselves in a catch 22; there are obvious security benefits to adopting Domain Name System Security Extensions or DNSSEC, but there are some severe downsides to being too early in the adoption curve – downsides that are becoming more and more apparent every day. While DNSSEC is getting rave reviews for successful deployment at the foundation levels of the DNS, problems are lurking just ahead, since very few widely utilized end-user applications are able to actually utilize DNSSEC at all. Simply put, DNSSEC can only work if it is supported throughout the hierarchy from publisher to visitor..."

Comments

Wow!!

[gstoddart]

Simply put, DNSSEC can only work if it is supported throughout the hierarchy from publisher to visitor...

News flash, cool new security technology only works when everybody is already using it and would require massive amounts of code to be changed.

Is anybody even surprised by this?

Re:Wow!!

[Monkeedude1212]

It's funny because that's not even the case here - they claim its not so much that "everyone" needs to be in on it, just "everyone" vertically speaking for their system, not necessarily the wide web.

While DNSSEC is getting rave reviews for successful deployment at the foundation levels of the DNS, problems are lurking just ahead, since very few widely utilized end-user applications are able to actually utilize DNSSEC at all

So basically: It works. But the features of it don't work if the application layer doesn't attempt to utilize it.

It doesn't seem to have any reason to NOT implement it, assuming you do it properly you won't have any negative effects. Like mucking around with your DNS Server anyways, if you don't know what you're doing you're likely to mess it up whether you are trying to setup DNSSEC or not. So really, there's nothing stopping anyone from implementing it - just their own laziness or fear of screwing up a working system (much like the delay in implementing IPv6).

I don't see the "Downsides" they really try to perpetuate though. They make it sound as though properly implementing DNSSEC is going to cause a rapid dropoff in sales if you attempt to deploy it before the rest of the market. Not true.

IPv6 deja vu

[magsol]

Isn't this the same problem faced by trying to undertake widespread adoption of IPv6? Maybe we should just do both at the same time - one massive headache that will hopefully last as short as possible, as opposed to two much longer (and likely overlapping), less intense headaches. Not that corporations who aren't running into any DNS cache poisoning or IP exhaustion issues (aka the vast majority) will be chomping at the bit to get these items done out of the fathomless kindness of their hearts.

Meh

[TheRaven64]

The entire point of the article seems to be 'if you incorrectly configure DNSSEC then people trying to connect to your systems will see DNS failures at the application level instead of a helpful error message'. This isn't an argument against deploying DNSSEC, it's an argument for deploying it correctly (and testing it in private DNS server before deploying!).

Re:Meh

[Jonner]

Another point of the article is that there will be PHBs that interpret a misconfiguration or risk of misconfiguration as a reason not to deploy DNSSEC. Unfortunately, that's very plausible.

This is NOT a chicken & Egg issue at all

[kevmeister]

The problem with DNSSEC are not at all "chicken & egg" in nature. It's one of the need for adoption from top to bottom and that is moving along well. It's simply a matter of critical mass. Many applications either are or can be DNSSEC aware. DNSSEC plug-ins are available for several browsers, but are pretty useless until the providers of name service enable validation. Until .com is signed AND registrars are accepting public keys for .com, DNSSEC to the end user won't happen, but that is coming, if rather slowly.

Another issue is maturing of software. DNS is critical to network operations and people are not going to be using it globally until the software available make this both reliable and easily implementable, it will often just happen. BIND V9.8 will get close and I hope BIND 10 gets us all the way.

Finally, DNSSEC is not free. It takes at least a bit of work to implement it, so I really don't think that you will see people signing DNS for the page with the family pictures. It will start with banks and such.

While there are some real issues ahead ofr DNSSEC, but its implementation seems to be going just fine for now.

Re:What downsides?

[Anonymous Coward]

The down side is the cost. It costs money in terms of software and/or labor to setup and maintain DNSSEC. A rational business person will make the decision to not implement DNSSEC because until your business or your customers can take advantage of DNSSEC it is a cost without benefit.

I don't expect banks to be the first to jump on this like others have speculated because the banks are not responsible for a customers loss when they connect to an untrusted 3rd, the customer is. The only real advantage supporting DNSSEC gets a bank is to be able to advertise to customers that they have this awesome new security feature, but then how do you explain to the average consumer how DNSSEC benefits them and that they should bank with Foo instead of Bar in a 15 second television spot?

It's all being worked on

[Effugas]

DNSSEC is an infrastructure shift, and you can't use it on .com domains for another few months. Have some patience.

At Black Hat this year, I actually demonstrated the endgame. Want federated authentication in OpenSSH that actually scales? Want servers able to autogenerate TLS keys that will be recognized and secured worldwide, even against broken certificate authorities?

Want secure email, without the mess that is PGP key management?

End to end secure key management via DNSSEC makes it all actually really easy. Code is here -- BSD licensed, feel free to play:

http://dankaminsky.com/phreebird

Also, I'm putting together a set of diaries on the subject:

http://dankaminsky.com/2010/12/13/dnssec-ch1/

Enjoy!

Re:It's all being worked on

[slimjim8094]

It doesn't seem like you understand what's going on here. Roots are trusted, they sign .com, .org, and so on, which sign your domain. I can verify that I'm talking to your authoritative servers by checking this trust chain, and since you can/will sign your own entries, I can verify from the top down that I'm getting the answer I should be.

This is where it gets cool. If we can trust the entries in DNS, why not put a public key there? I know it's accurate, so when I SSH I can verify the first time that it's correct. Or I could self-sign a SSL certificate - which is fine for encryption purposes - and put the fingerprint in DNS to ensure it's not tampered with.

Basically the roots replace the CAs in the trust model. It's at least as secure as the CAs, but there's a lot less of them and it's easier to safeguard your own private key than it is to trust every single one of the dozens of CAs to do their homework.

It also has the benefit of any tampering being much easier to notice, because it breaks everything under it.

So I'm not quite sure what you think the problem is, except that you're worried your registrar will charge you $300/yr for a certificate record... in which case you could switch to a decent registrar.

Re:It's all being worked on

[Junta]

I understand, but OpenSSH right now only does anything *particularly* interesting wrt SSHFP records and DNSSEC by checking the AD flag in the response from the nearest nameserver instead of doing the cryptographic validation itself, leaving a hole open as well as making it awkward when your nearest nameserver is authoritative for the SSHFP record of interest.

I'm not sure if DNS is fundamentally better than x509. I'm not sure compromised DNSSEC keys would be any more obvious than compromised CA keys. I think before x509 was defined, that DNSSEC would have had a whole lot of value. I think for applications that by and large ignore x509 (e.g. OpenSSH) there is an opportunity, but only because they ignored an existing approach.

Applications don't need support

[Todd Knarr]

One thing here is that applications, and even end-user computers, don't need to support DNSSEC directly. It's good if they do, and once they do they can do some interesting things with it, but in practice most end-user computers don't do full DNS anyway. They've got a stub resolver that hands the real work off to the DNS servers on the network they're on, and those handle the heavy lifting. If those DNS servers implement DNSSEC and check records properly, all the computers on the network get the basic benefit of non-forgeable DNS records (if the signatures don't verify, the local DNS servers will return an error to the client).

Even getting it into the home isn't too hard. Most ISPs use DHCP to assign addresses to customers and point customers to the ISP's DNS servers in the process, so if the ISP's DNS servers implement DNSSEC the customers get the benefit. And for users with their own router, all it takes is DNSSEC in the router's firmware to move the verification all the way to the edge of the home LAN. That's not hard, my Netgear router uses a custom Linux system in the firmware and it's not too hard to tweak the DNS software on it. If I can do it, the router manufacturer can surely do it too and make the new firmware available just like they do for any firmware upgrade. The only real issue is hardware horsepower to do the calculations to verify the signatures. Some consumer routers don't have enough.

Re:Applications don't need support

[Junta]

If those DNS servers implement DNSSEC and check records properly, all the computers on the network get the basic benefit of non-forgeable DNS records (if the signatures don't verify, the local DNS servers will return an error to the client).

One thing I never quite got. While DNSSEC is not ubiquitous, if someone hijacks some part of it in a way that DNSSEC would protect against in theory, what stops them from skipping all the DNSSEC stuff they can't fake. The resolvers will drop incorrect DNSSEC data, but will accept records with no DNSSEC, and just not set AD flag that most things don't care about (and really can't know whether to care or not).

Re:Applications don't need support

[Todd Knarr]

Because the higher-level zone reports it as secured. So if I DNSSEC-secure silverglass.org, then when someone goes to look up a host they first go to the .org servers and get the silverglass.org delegation information which includes the public key record used to verify the silverglass.org records. The .org servers in turn have their records secured, and you get the public key for them from the root DNS servers. The root zone in turn is secured, and it's public key is pre-loaded into the DNS server's software. So if someone tried to hijack the silverglass.org domain and return unsigned records, they'd first have to hijack the .org domain so they could remove the public key record from the delegation information there. That in turn would require hijacking the root DNS servers themselves to remove .org's public key information. And that would require breaking into the target DNS servers to remove the root DNSSEC key from their configuration. Of course if you've done that last you could just disable DNSSEC entirely. But now you're talking attacking every single network on the entire Internet, or at least every network whose users you want to target with your DNS hijacking, which is a whole lot of work.

Re:DNSSEC HOWTO?

[Junta]

The best I can suggest off hand would be ftp://ftp.isc.org/isc/pubs/pres/NANOG/50/DNSSEC-NANOG50.pdf and other things linked from http://www.isc.org/software/bind/dnssec. That one presumes 9.7 which means they got to skip a lot of the nastiness other commonly referenced guides go over. I don't think I've seen a guide that doesn't present it as more complicated than it is, but that isn't too bad.

That all assumes ISC bind, and I particularly recommend BIND 9.7 or newer as a starting point (it had some *major* simplifications on DNSSEC).