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!!

[linuxgeek64]

z0mg!

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.

Re:Wow!!

[Anonymous Coward]

Reason preventing adoption: Cost of fielding troubleshooting phone calls and/or meetings exceeds value of implementing it.

Re:Wow!!

[TheRaven64]

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 show a 'unable to resolve host' error.

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.

Re:Wow!!

[Effugas]

We can do this incrementally, mostly because we're just *not* securing most things right now. So the conversion cost is lower than you'd think.

Re:Wow!!

[psydeshow]

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 is broken for this site" message.

Re:Wow!!

[Anonymous Coward]

No, the current model is, applications won't even see this
or have the ability to respond.

It's failed at the resolver - the domain no longer exists.

This is "fail closed", a security paradigm. It's a mistake,
but one the DNSSEC standards folks chose to make.
Maybe this will happen to somebody important and
this will be changed.

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.

Re:IPv6 deja vu

[Anonymous Coward]

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.

OK, everyone. On April 1, 2011, everybody change their servers, routers, home computers, iPhones, fridges and networked toasters, over to IPv6.

Due to the lack of a 1:1 ratio of sysadmins to regular (non-techy) folks, Best Buy/A+ technicians will be assigned 100 people in their area, junior systems and network technicians will be assigned 1000 people in their area, and senior network and sysadmins will be assigned 20, 000 people in their area. Please have all machines updated by the end of the day. This should provide ample coverage for techy to non-techy people.

Also, make sure any old systems that do not support IPv6 are upgraded.

Re:IPv6 deja vu

[KublaiKhan]

It would certainly be a marketing coup, especially if the corporations who decided to adopt it put out a browser plugin or something to ensure 'lock-in' to their proprietary 4->6 gateway services on the consumer side....

Re:IPv6 deja vu

[CAPSLOCK2000]

Please, also implement IPSEC while you are at it. IPSEC nicely brings IPv6 and DNSSEC together.

Re:IPv6 deja vu

[Jonner]

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 otherwise orthogonal. DNS (and therefore DNSSEC) is a protocol built on top of IPv4 and/or IPv6. Other than the ability to return either version of IP address, DNS doesn't care which version of IP it's used on.

Re:IPv6 deja vu

[Anonymous Coward]

...and while you're at it, let's change SMTP because it sucks and is insecure.

I can see where this is going pretty quickly.

Re:IPv6 deja vu

[Abcd1234]

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:IPv6 deja vu

[CAPSLOCK2000]

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:IPv6 deja vu

[Abcd1234]

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, 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 make such a system a reality.

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

[Effugas]

Applications will never, ever tell you anything bad about DNSSEC.

They might tell you a TLS validation failed, but that an IP was good or bad? No.

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.

Re:Meh

[John Hasler]

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.

It is. It may not be an adequate reason, but it is a valid concern.

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:This is NOT a chicken & Egg issue at all

[vlm]

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, again, something you'll notice in a graph but in an absolute sense is probably a rounding error...

Re:This is NOT a chicken & Egg issue at all

[Anonymous Coward]

The load on the DNS server stems from the DNS UDP response to a DNSSEC TCP response.

What downsides?

[Just Some Guy]

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 actually be a problem.

Re:What downsides?

[vlm]

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 Dexter Ward" failure pattern, which should frankly not be new to ... anyone? Isn't it always the case that the skill level to "do something" is always way the heck underneath the skill level required to "fix something"?

(Charles Dexter Ward is the HP Lovecraft story most famously known for the "don't call up what you can't put down" line, w/ regards to necromancy.)

Re:What downsides?

[DarkOx]

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. Those extra signing records might be there but my computer won't ask for them. Until the client side software supports it, they can still be attacked via DNS poisoning. So anyone who setup DNSSEC has gone to allot of trouble which most users won't be able to get an immediate benefit from.

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?

Re:What downsides?

[Anonymous Coward]

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 connected to a network and then sneaker-net them to your name server. Copying them over the network opens them up because if you encrypt from a key that's on the network, like your name server, that machine could be compromised and that encryption key stolen and a keylogger grabs the password you type. Granted, it's most likely not to happen. Therefore automation is out of the question unless you have a way to protect your keys in memory.

As a user though, since there's no visibility (other then a Firefox plug-in), a user would be ignorant to what's going on with DNSSEC.

Re:What downsides?

[vlm]

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:What downsides?

[Anonymous Coward]

If said magic wand worked as advertised, you would be running DNSSEC. There is no downside for you, because the downside is the deployment hassle. Your customers would get basically no benefit from it though. Not yet. 99.5% of users don't know what DNSSEC is, so the fact that their system doesn't support it in any meaningful way isn't a big deal. Therefore, late adoption, probably through forced patches, and that's going to take a few years to roll all the way down the hill.

Re:What downsides?

[CAPSLOCK2000]

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:What downsides?

[Junta]

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:What downsides?

[isj]

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 response will be be signed.
Another mechanism is to only redirect the HTTP request and respond with a 301 or login page. This should still work with DNSSEC.

So the big players, are probably a bit reluctant to enable DNSSEC on their domain because of the users that happen to sit behind the first type of captive portal.

I actually dislike the first mechanism, because even when it can be implemented nicely, many captives portals forget to set DNS response lifetime to 0 seconds so that when you have signed in/up, your DNS resolver will retry the query. Webbrowser reload only results in the you getting the login page again. So when connecting to a wifi network I don't know the details about I always first go to a webpage that I don't want to go to.

Re:What downsides?

[kasperd]

I don't see how captive portals that rely on DNS tricks will work.

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.

• Provide some domain to search under through DHCP.
• Cause DNS lookups to the domain requested by the user to fail with server error
• When search is repeated under search domain, give IP of redirection server.
• Once user is signed up allow them to lookup the real DNS records.
• Optionally the redirection server could act as transparent proxy if the user is already signed up.

Another mechanism is to only redirect the HTTP request and respond with a 301 or login page. This should still work with DNSSEC.

This is how most of them behaves because it is the most reliable way to work around the problems caused by the records being cached. Some such systems also redirect https, which obviously leads to browsers warning about incorrect certificates. This is very annoying if you had your laptop suspended with some open ajax applications. I wish browsers could be configured to just consider it an error, and not ask me every time it sees an invalid certificate.

The only reason it works with HTTP is that there is no end to end security. It only protects DNS, not the connection you create to the returned IP afterwards. That could of course be implemented using some additional DNS records with public keys. Such a system might actually turn out to be easier to deploy than https, so it could look like a threat to the current CAs.

So the big players, are probably a bit reluctant to enable DNSSEC on their domain because of the users that happen to sit behind the first type of captive portal.

I doubt that is the reason. They are basically allowing somebody to perform a man in the middle attack against the connections to their server. They may think these man in the middle attacks are only used for good purposes, but they have no control over that.

I actually dislike the first mechanism, because even when it can be implemented nicely, many captives portals forget to set DNS response lifetime to 0 seconds so that when you have signed in/up, your DNS resolver will retry the query.

Browser and/or resolver may still cache the entry even if it has ttl 0. In fact some browsers do it deliberately for security reasons. There are some javascript based attacks that can be performed if you change an A record from pointing at a malicious server to point at a site where you want to perform some sort of attack. (Or maybe it was the other way around, sorry, I don't remember all the details). It is a quite broken security model, and arbitrarily caching lookups past expiry is a terrible workaround.

So when connecting to a wifi network I don't know the details about I always first go to a webpage that I don't want to go to.

I went as far as creating a bookmark in my browser for that exact purpose. If I do get through to the server in question, it will redirect me to my own homepage.

Re:What downsides?

[badkarmadayaccount]

PKI anyone?

Re:What downsides?

[Anonymous Coward]

Are you inferring that IPv6 = Cthullu ???

While it's not ideal

[Anonymous Coward]

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!

[hey]

Did I just see an Slashdot article summary that explained the acronym ??!!!

Re:acronym explained!

[marcosdumay]

You want the summary to explain what DNSSEC is? Do you also want the definition of the words "chicken" and "egg"?

Wrong acronym

[neo-mkrey]

It should be DNSSEX. Right? Right? Hello? Buehler?

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

[Anonymous Coward]

Slight error, you can use it on .com, it's just not signed from the top, just from DLV.

Be that as it may, I don't know too many .com's that are signed.

Re:It's all being worked on

[Simmeh]

Nice, but slide 13 is bork.

Re:It's all being worked on

[Junta]

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 equally quality protection without your parent domain charging you to establish the trust relationship. I wonder if that will happen in practice, it's too much of an unknown right now. I'll predict that ultimately, either parent domains will be too fast and loose about getting the trust relationship going compared to current CAs, or else those parent domains will charge probably an equivalent 'processing fee' to cover their costs of validation. Also, there is a presumption here that all applications will do the right thing. SSH could have done x509 instead of known_hosts but they *chose* to do their own thing, I suspect that will continue to be the case, that the DNS web of trust will be as likely to be ignored as the x509 web of trust. The optimal thing could happen, but I'm skeptical that DNSSEC will really offer anything new/better than x509 certificates today once the dust clears.

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.

Re:It's all being worked on

[slimjim8094]

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, incomplete implementations that will be fixed as it's deployed more widely.

Re:It's all being worked on

[baerm]

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.

IPSEC FBI Trojans?

[Anonymous Coward]

Do DNSSEC version contain OpenBSD's secret FBI IPSEC back doors?

My least favorite sentence of the day

[glwtta]

very few widely utilized end-user applications are able to actually utilize DNSSEC

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:My least favorite sentence of the day

[mcgrew]

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 have "PhD" after their name in all correspondence, and never use a one syllable word when a three syllable word will do.

Re:My least favorite sentence of the day

[Anonymous Coward]

he may also just be a native french-speaker who's using "utilized" instead of "used" because "utilise" makes sense here!? It's the same thing as the first time I spoke to an american friend of mine of a "labyrinth" to mean a "maze" and he told me: "you're using such a sophisticated vocabulary!"... But then in french it's pretty normal to say "labyrinthe".

Re:My least favorite sentence of the day

[Anonymous Coward]

Their motto must be "never utilize a one syllable word when a three syllable word will suffice.

Actually, it's "Monosyllabic intercommunications achieve semantic feasibility exclusively upon the denouement of exhaustive analytic consideration whereto disestablishment of lexicographical variants is descendant."

btw- Ph.D. == Phony Distinction --often, though not always true. :)

Re:Big Brother.

[Lunix Nutcase]

So commodore64_love is now posting his Alex Jones rants as an AC?

DNSSEC HOWTO?

[metamatic]

Is there a good tutorial on setting up DNSSEC for your network? I've got DNS caching on my home network, and would be interested in getting DNSSEC verification of DNS results set up if it's not too painful.

Re:DNSSEC HOWTO?

[Anonymous Coward]

There's a multi-page (100?) howto at NIST. It's not a trivial thing to set up correctly unless you buy an appliance (there's only one that's secure).

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).

Re:DNSSEC HOWTO?

[baerm]

Since no one mentioned yet, http://www.dnssec.net/ is also a good information site.

firefox plugin

[Anonymous Coward]

One of the applications that can directly show the user if the website he/she is visiting uses DNSSEC is Firefox. There is a plugin for it here

INTERNATIONAL UPGRADE DAY - JANUARY 15

[Aggrav8d]

It's my favorite holiday. All the plebs stay home and the admins get to all make the Big Changeover simultaneously. Big sales in survival gear, canned food, and backup drives.

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

[slimjim8094]

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: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.

We'd be better served by hosting for IPv6sec

[WillAffleckUW]

We'd be better served if we just migrated to DNSSEC running for IPv6 addresses only.

When the underlying IPv4 stack is inherently non-secure, running a secure DNS on top is kind of a waste of time.

Plus, bonus - this would encourage people to swap over to IPv6, and if you've got a Microsoft or Linux or Mac OS machine bought in the last few years, it already is running IPv6 stacks as well as IPv4 stacks.

But it doesn't work in practice..

[Junta]

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 certain applications that are particularly careful about checking the AD flag, you are unable to trigger their 'secure' features on records for which you are authoritative, because the AD flag will not be set for local records. I'm looking at OpenSSH particularly hard here.

Now if you push things so that the software does cryptographic validation (like in SSL), it becomes very very hard to maintain a private infrastructure without full path protection to the root zone because you have to push all your islands key data to applications. DNSSEC would be great if it was there from the beginning. Part of SSL addressed dubious DNS results and now with DNSSEC, there is a bit of redundancy in practice for the common cases of DNS hijacking. I really really wished SSH had used x509 as the framework for their public-private keys instead of doing their own thing, ssh is probably the application that has the most to gain from DNSSEC and that isn't enough for most things to care.

Re:But it doesn't work in practice..

[Architect_sasyr]

-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 beyond a "getaddrinfo('slashdot.org'); connect(lookupresult);". Those shenanigans may still occur, but they're really part of the operating system (one application) rather than many.

Re:But it doesn't work in practice..

[kasperd]

This means that anyone able to spoof their way between you and your nameserver can *still* compromise DNS.

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.

This is better than the current state of things which is subject to shenanigans in a much wider scope, but still.

Exactly. The immediate problem we are facing is the possibility to poison caching name servers shared by many users. An attacker sends requests and forged responses more or less simultaneously to a server, and with a bit of luck gets a forged record cached. If we can get such servers to verify DNSSEC signatures we may have fixed the weakest point that we currently have. As such it is only a small part of the infrastructure that actually needs to be updated before we start getting some benefit. Once that part is in place we can get a bit more benefit from deploying checking all the way to the clients.

I'm looking at OpenSSH particularly hard here.

The way ssh currently works, it doesn't make a huge difference if the DNS records are signed or not. Either you get a DNS record with an invalid signature, and you just never connect to any server, or you get an incorrect IP and connect after which ssh reports the server has a wrong host key. The attacker could also try to just hijack the TCP connection without giving you an incorrect IP address, in that case ssh would also report a wrong host key.

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.

Re:But it doesn't work in practice..

[Junta]

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 implementation where an application has no idea how much assurance backs the data unless it digs into things deeper.

Re:But it doesn't work in practice..

[Junta]

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 needed, validity is assured via a chain of trust, and people don't blindly accept new keys for lack of convenient alternatives.

Re:But it doesn't work in practice..

[kasperd]

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.

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.

If SSH however uses DNSSEC assurance as a trusted way of updating known_hosts, it becomes a vector for man in the middle.

If ssh used DNSSEC to update the known hosts file without asking the user for confirmation, it would be a significant drop in security. If ssh updated the known hosts file just because it had use DNSSEC to verify the correctness of the IP address it was connecting to, without having received any information about the new key, that would be plain stupid.

If ssh however could get the public key from DNSSEC and store it in the known hosts file the first time you connect and not yet have the key in your known hosts file, then it would improve security. (As with anything, if the improved security causes users to be less careful, then it may not make the system more secure after all.)

Guess I should say that is SPECIFICALLY what I am talking about. SSHFP records are fingerprints of host public keys.

Nice, I didn't know about RFC 4255 before now. This is the kind of thing I had in mind, I didn't know it already existed.

*If* DNSSEC were implemented in a way where validity is assured by the local system, then known_hosts isn't needed, validity is assured via a chain of trust, and people don't blindly accept new keys for lack of convenient alternatives.

I'd not trust it as an alternative to known hosts, but as a supplement it sounds like a good idea. The problem with the DNSSEC chain of trust is that you have to trust a lot more parties than you do with the known hosts file.

Re:But it doesn't work in practice..

[Junta]

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 displace some insecure workarounds commonly in place.

Nice, I didn't know about RFC 4255 before now. This is the kind of thing I had in mind, I didn't know it already existed.

Yes, already implemented in current OpenSSH. Been playing with it and it will provide enhanced trust if AD flag is set, so it won't help for locally authoritative data. I haven't tried it, but have been wanting to play with https://www.dnssec-tools.org/wiki/index.php/Ssh. I've been getting on a soapbox in the hopes some OpenSSH developer will take note of that.

I'd not trust it as an alternative to known hosts, but as a supplement it sounds like a good idea.

I'll admit that perhaps it shouldn't be by default, but it should be an option for places that torture the ssh config today in worse ways in order to simplify ssh administration at the cost of security.

Re:But it doesn't work in practice..

[kasperd]

If DNSSEC works perfectly (i.e. data cryptographically validated on the local host), then it may displace some insecure workarounds commonly in place.

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 which you get different keys from /etc and from DNSSEC, and assume that keys in the users own known hosts file were obtained from DNSSEC in the first place and just ask the user for confirmation before updating it. Obviously it should be possible to change the configuration to make the policy whatever you want.

Multi utilize is preferable to the L word

[Vainglorious Coward]

Just be thankful the author didn't leverage DNSSEC