The DNSSEC Chicken & Egg Challenge 77
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..."
Wow!! (Score:3)
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!! (Score:5, Interesting)
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.
Re: (Score:2)
So basically: It works. But the features of it don't work if the application layer doesn't attempt to utilize it.
Not even that, just you don't get a useful error message if the application layer doesn't attempt to utilise it. It's implemented in the resolver. By default, you'll look up example.com in your application, the resolver will ask the DNS cache for example.com, get something that fails the DNSSEC check, and return no results. Your application will see no host exists for example.com (either because the DNS admin at example.com is a muppet or because there is some kind of DNS poisoning going on) and will sho
Re: (Score:2)
The only 'problem' is that it's harder to diagnose the problem. It could be that your DNS server is broken, the client's DNS cache or resolver is broken, or that someone is poisoning the DNS cache. Unless people on the client side are resolving technical issues for you, this really isn't a problem - a minute or two with dig will let you discover which of these it is.
But that's actually really important, because silently failing or failing with a cryptic error will cause users to blame you for the problem, when in fact it is their machine/network/DNS that is poisoned.
Applications need to be rewritten to handle the case where the name resolves but to an unsigned or wrongly signed record, so that the user can ask an appropriate person for help.
That said, applications should not ever offer to allow the user to continue to the domain anyway. It's just a "hey, your network i
But it doesn't work in practice.. (Score:2)
So yes, you can build a DNSSEC island and have that island internally consistent. However, some things about how DNSSEC is done bug me that make me question its value:
-Applications are generally not cryptographically validating the DNS response, they simply check the AD flag. This means that anyone able to spoof their way between you and your nameserver can *still* compromise DNS. This is better than the current state of things which is subject to shenanigans in a much wider scope, but still.
-When certai
Re: (Score:2)
-Applications are generally not cryptographically validating the DNS response, they simply check the AD flag. This means that anyone able to spoof their way between you and your nameserver can *still* compromise DNS. This is better than the current state of things which is subject to shenanigans in a much wider scope, but still.
Shouldn't the applications be just one - the system DNS resolver? If named or whatever microsoft use is doing the lookups for you, then the onus is on the system software to validate the DNS request and either hand it up the chain, if it works, or send up a failure (or nothing at all) if it doesn't. Those of us who need tools that are of a better consistency and have debuggable output can use them, but the majority of applications shouldn't even be seeing DNSSEC any more than they should be seeing IPv6 beyo
Re: (Score:2)
The notable issue being things like SSHFP, where the application must know how secure it is to provide reasonable treatment. If the result is not thoroughly validated in a way that is impervious to hijack, then ssh can treat that as an authoritative source wherease without that guarantee, it's nothing more than a hint.
Admittedly, if things were perfect, then the resolver returning anything always guarantees that the result was validated *on your machine specifically*. But we have this partial implementati
Re: (Score:2)
Anybody who could do that could probably pull off the same hijacking without spoofing a DNS record. Even if you have the correct IP of the server you want to talk to, they could hijack your traffic to that IP. It does give them one more point to attack, so it still means there is a reason to protect that part of the communication, however it isn't currently the weakest point.
Re: (Score:2)
Anybody who could do that could probably pull off the same hijacking without spoofing a DNS record
Only if the protocol is crappy. Sure, telnet, http without SSL and friends would be vulnerable, but https and ssh would not be directly attackable in this way. If SSH however uses DNSSEC assurance as a trusted way of updating known_hosts, it becomes a vector for man in the middle.
The real case for ssh using DNSSEC would actually be if host keys could be put in DNS as well. However it is unclear to me if that would be anymore secure or easier to maintain than a known hosts file.
Guess I should say that is SPECIFICALLY what I am talking about. SSHFP records are fingerprints of host public keys. *If* DNSSEC were implemented in a way where validity is assured by the local system, then known_hosts isn't ne
Re: (Score:2)
As it stands now, DNSSEC mainly protects those protocols that don't have their own protection built in. I think the majority of attacks you would protect against would be on http. I think it would be a while before https and ssh would see any benefit from DNSSEC.
Re: (Score:2)
If ssh used DNSSEC to update the known hosts file without asking the user for confirmation, it would be a significant drop in security
Depends. In some environments, measures are taken to alleviate the problem of ssh requiring to go interactive to deal with key updates (can be induced by reinstalls or by things like fixing the debian host key generation problem a while back). Those measures frequently either compromise the secrecy of the host keys or provide known_hosts via a shared filesystem strategy that is likely to be less than secure. If DNSSEC works perfectly (i.e. data cryptographically validated on the local host), then it may
Re: (Score:2)
It is possible to distribute the known hosts file in a secure way. But of course it is also possible to do it in an insecure way. Those organizations that care enough about security to implement a secure distribution of a known hosts file, shouldn't be forced to trust a key obtained via DNSSEC. A reasonable default would be to refuse to connect to a host for w
Re: (Score:2)
IPv6 deja vu (Score:4, Insightful)
Re: (Score:1)
Re: (Score:2)
Please, also implement IPSEC while you are at it. IPSEC nicely brings IPv6 and DNSSEC together.
Re: (Score:2)
Huh? IPSec is everywhere, today. It's not mandatory for v4, but it's out there. Our company uses it to power the VPNs to our remote sites.
In v6, it's mandatory, so naturally, if you deploy v6, you get IPSec.
Re: (Score:2)
Right now ipsec requires you to pre-share secrets. There is no way to do ipsec with any random host on the internet. You need a way to share keys in a reliable way. DNS could do it if it were reliable, hence the need for DNSSEC.
Re: (Score:2)
Right now ipsec requires you to pre-share secrets.
Not true. While preshared keys are *one* way to negotiate an IPSec tunnel, you can also use standard public/private key pairs.
Of course, then you have the issue of building out public key infrastructure [wikipedia.org], and DNSSEC happens to provide a nice solution for that problem. But it isn't the *only* solution by any means. The real, underlying problem is that an internet-wide PKI system was never established... and you are correct, in that DNSSEC might finally mak
Re: (Score:2)
It's not very interesting to ask whether we should adopt both technologies at the same time, since that's already happening. The transition to IPv6 has been happening for many years, though far too slowly. The transition to DNSSEC just started recently.
The problems are only similar in that the value of adopting either IPv6 or DNSSEC is dependent on the number of other people doing the same. In other words, like most things on the Internet, it's all about network effects. However, the two problems are otherw
Meh (Score:3)
Re: (Score:2)
They might tell you a TLS validation failed, but that an IP was good or bad? No.
Re: (Score:3)
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.
Re: (Score:2)
It is. It may not be an adequate reason, but it is a valid concern.
This is NOT a chicken & Egg issue at all (Score:3, Informative)
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: (Score:2)
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.
You mean that facebook thingy that I don't use anymore? I'm not sure, but I think they can afford it.
Also the load on the DNS server increases. Not to spectacular levels, no. But you'll probably have to fool around with your vmware / xen / whatever virtualization software if you've cranked your DNS server back to 25 MHz equivalent cpu cycles and 8 megs of ram (which actually would have been a pretty decent server in the early 90s when I was starting out). And you'll need a wee bit more network traffic,
What downsides? (Score:2)
This is probably answered in the article, but let's be honest: most of us aren't going to read it. So, what exactly are the downsides to deploying DNSSEC today? If I could wave a magic wand and have it up and running on my server 5 minutes from now, what would break or otherwise be worse than what I have right now? I can understand the idea that maybe clients won't get the full benefit until they're configured to check any DNS requests they make to me, but I'd be hard pressed to think of why that would actu
Re: (Score:2)
So, what exactly are the downsides to deploying DNSSEC today? If I could wave a magic wand and have it up and running on my server 5 minutes from now, what would break or otherwise be worse than what I have right now?
No downsides, and nothing.
The article is a couple hundred word rant on the topic of, if you screw up, it won't work.
Standard slashdot car analogy: If I screw up while changing the oil in my car the wrong way, perhaps by using a cutting torch to remove the drain plug rather than using a socket wrench, or by turning the car upside down to drain the oil out the fill port, like I do with my lawnmower, then, possibly, something might break.
Also a bit of a rant about the "sorcerers apprentice / Case of Charles D
Re: (Score:2)
Well the only real issue is the lack of utility. Obviously there is some risk associate with making modifications to critical infrastructure systems. Lots of organizations like to avoid doing it for that reason until they have to do so, after all it aint broke don't fix it.
Other posters have compared DNSSEC to IPv6 which to me is kinda silly. DNSSEC is an extension it does not effect existing standard operations. IE my outdated stub resolver in my operating system will continue to talk to DNS just fine.
Re: (Score:2, Insightful)
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 supporti
Re: (Score:2)
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 first to jump will be the online merchants, because they don't want their trademarks diluted by crooks spoofing them. Pretty much any service where you give them money to make your account password do something. Pay pr0n websites, probably, they're always the first with every other technology.
Re: (Score:2)
The problem for *any* web oriented 'benefit' of DNSSEC is if the client is in a position where DNSSEC would help, they are already in trouble. If they don't assure the browser is talking securely (SSL) to the peer with the existing mechanisms to show the user, then they are hosed no matter what you do. If they are a customer that does check, DNSSEC doesn't validate things any more than the x509 certificate the server has. It's an alternative, redundant validation of DNS data now.
Re: (Score:1)
Re: (Score:1)
The downside is the complicated nature of deploying DNSSEC. Using your standard name server, the deployment of keys to the production systems is where the problem comes from. The keys for DNSSEC are frequently generated and if you miss your windows of when you can put in the new keys, you could knock your DNSSEC deployment off line. The problem stems from the fact that our general purpose OS's are not secure. The only way to ensure the security of your keys would be to put them on a machine that is not
Re: (Score:2)
So commodore64_love is now posting his Alex Jones rants as an AC?
Re: (Score:2)
It's harder to debug. Error-messages may be misleading or may not occur at all.
If things break, somebody will have to pay for it, some companies will thus avoid it.
That's the whole story.
Re: (Score:2)
I don't see how captive portals that rely on DNS tricks will work.
For those who don't know: A captive portal is used for directing you webbrowser to a specific page, eg. when you access a for-pay wireless network and it redirects you to a webpage where you can log in or sign up.
One mechanism is to capture the DNS query packet, and respond with, say, 192.168.0.1, where that server will respond with either a HTTP 301 redirect or the login-page. I cannot see how this will work with DNSSEC because the fake resp
Re: (Score:2)
In short, they are not supposed to. This is really a dirty hack to work around the lack of any standard way of setting up such a signup system. A slightly cleaner approach, that I don't know how well would work, would be as follows.
While it's not ideal (Score:1)
The idea is to push trusted information closer to the end user. Once ISP's implement DNSSEC then you be sure that the records you are obtaining have been verified all the way up to the root. That doesn't get it all the way to the end user....but it is a vast improvement.
acronym explained! (Score:2)
Did I just see an Slashdot article summary that explained the acronym ??!!!
Re: (Score:2)
You want the summary to explain what DNSSEC is? Do you also want the definition of the words "chicken" and "egg"?
Wrong acronym (Score:1)
It's all being worked on (Score:5, Interesting)
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: (Score:2)
Re: (Score:2)
Want federated authentication in OpenSSH that actually scales?
Is OpenSSH actually going to do crypto-verification or are you advocating the current mess where it just checks AD flag and nothing more?
Want servers able to autogenerate TLS keys that will be recognized and secured worldwide, even against broken certificate authorities?
It really just replaces one web of trust with another. Replace broken certificate authorities with broken DNS key anywhere between your domain and root.
Want secure email, without the mess that is PGP key management?
Sure, PGP key management is all sorts of fubar for establishing trust. x509 certs would be fine here. The obvious issue is that the accepted x509 CAs frequently charge a bit and the dream is that DNSSEC will provide equa
Re: (Score:3)
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 c
Re: (Score:3)
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 thi
Re: (Score:2)
I see what you're saying, but there's no reason you can't use them together. x509 is great for encryption, and webservers and browsers already support it. What I alluded to was, why not put an x509 cert fingerprint in the DNS? I don't like relying on some third-party money-grubbing infrastructure to re-authenticate a domain name for me. Why not just let me trust the domain name? Hence DNSSEC
There are some problems, and major, that you point out. But I don't see any that aren't easily fixable - as in, incomp
Re: (Score:1)
Yes, without doing local resolution, there is a possible vulnerability between the DNS resolver and the host.
Without checking the openssh website, though, I think you can assume that if they don't have local dnssec resolution yet, they will have it, at least as an option, in the future. I.e., there are a number of dnssec resolving libraries available for them to use, so it be a matter of choosing one and patching their code to support it. It's just a question of when.
My least favorite sentence of the day (Score:2)
Good thing you managed to work "utilize" in there twice. The first one doesn't even really make sense grammatically, but hey, it sounds much more sophisticated.
Re: (Score:2)
Good thing you managed to work "utilize" in there twice.
He's probably the guy who wrote a paper I had to suffer through at work about fifteen years ago. It used the word "enumerate" five times in a single paragraph without once using the word "count". Their motto must be "never utilize a one syllable word when a three syllable word will suffice.
I've found that the smartest peole I've known have PhDs, and you wouldn't know it unless you found out by accident, and some of the dumbest people I've known all hav
Multi utilize is preferable to the L word (Score:2)
DNSSEC HOWTO? (Score:2)
Re: (Score:3)
The best I can suggest off hand would be ftp://ftp.isc.org/isc/pubs/pres/NANOG/50/DNSSEC-NANOG50.pdf [isc.org] and other things linked from http://www.isc.org/software/bind/dnssec [isc.org]. 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 *majo
Re: (Score:1)
Since no one mentioned yet, http://www.dnssec.net/ [dnssec.net] is also a good information site.
INTERNATIONAL UPGRADE DAY - JANUARY 15 (Score:2)
Applications don't need support (Score:3)
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: (Score:3)
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: (Score:2)
Because there's a trust chain. We can verify that the domain is supposed to be signed if .com says so, and we can trust that based on the root keys. Individual records can (I think) be left unsigned, but the domain can state that securely.
Re: (Score:3)
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 softwar