Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

netbuzz writes "Eighty percent of US federal agencies — including the Department of Homeland Security — have missed a deadline to deploy DNS Security Extensions, a new authentication mechanism designed to prevent hackers from hijacking Web traffic. The deadline that whooshed by was Dec. 31, 2009. Experts disagree as to whether this level of deployment represents a failure or reasonable progress toward meeting a mandate set by the Office of Management and Budget in the summer of 2008. OMB officials declined to say why the agency hasn't enforced the DNSSEC deadline for executive branch departments."

I'm not a huge fan of DHS, but come on there are so many other government agencies that hardly ever get any abuse at all. DHS has had a lot of cock ups, and should be ridden hard to shape up or dissolve, but this is hardly an opening sentence kind of cock up.

Now where is the full list of orgs that have or have not done it? I suspect its going to be a lot like reading the pork report.

The reason why the DHS gets more attention here than other departments is because they are the Department of Homeland Security. The importance of irony when ridiculing the government is not to be overlooked.

Seriously, this time I could even understand if it was not released for "reasons of national security". It would be one of the few cases where that excuse actually makes sense.

Because the terrorists who are going to attack using a sophisticated DNS cache poisoning technique are obviously too stupid to download a list of government websites and go through them one-by-one to see which are using DNSSEC.

And I quote:I'm not a huge fan of DHS, but come on there are so many other government agencies that hardly ever get any abuse at all. DHS has had a lot of cock ups, and should be ridden hard to shape up or dissolve, but this is hardly an opening sentence kind of cock up.

Now where is the full list of orgs that have or have not done it? I suspect its going to be a lot like reading the pork report.

Seems that most of the larger (well-known) *.govs doens't haven't deployed dnssec. I tried cia.gov, fbi.gov, nsa.gov (!), state.gov, whitehouse.gov, ins.gov, irs.gov... state.gov was the only one i found having published a DNSKEY rr. (I just picked a few at random I knew)

Who comes up with names like these? "Homeland" is disturbingly close to "Vaterland." Wouldn't "domestic" have worked?My county renamed the Sheriff's Office to "Department of Public Safety," bringing to mind that laff-riot Reign of Terror during the French Revolution.

And yes, DHS could easily have been made part of the FBI or the US Marshall's Service, if it needs to exist at all.

Most deadlines in the government are doomed from the beginning . . . there is so much that most projects have to go through just to get considered not counting the implementation phase it is ridiculous. Until folks have actually worked within the government they'll never understand.

1) look good2) are well spoken (talk a load of shit, but do it well)3) have the majority of their education devoted to playing the system (lawyers, MBAs, etc.)4) are endorsed by moneyed interests

rather than people that:

1) Look normal2) Act dumb on camera but get shit done3) Have the majority of their education devoted to their field of expertise (Doctors, Engineers, Climatologists, etc.)4) are endorsed only through public funds.

I can certainly understand the unreasonable deadline complaint, but why exactly is DNSSEC "just some product being pushed by a shill company"? BIND implements DNSSEC, it's not like it's a proprietary piece of technology that is only offered by a single vendor.

I'm not arguing that it should be easy to do, or that their deadline was reasonable. I've worked with BIND before and fully acknowledge that it's a bitch and a half. What I'm asking about is why the original poster seems think that DNSSEC is a worthless product being pushed by a single company looking to make a buck.

Because ISC is one of those companies that is pushing DNSSEC and a lof ot other DNS-companies are not, because they think it's a bad idea to implement something which is so complicated. Many security bugs arrise when things start to get complicated.

I'm pretty sure more money has gone into lobbying against DNSSEC than in favour... it's going to have a really big toll on the CAs after all when everyone can just put a self-signed cert inside their DNS entry and have end to end authentication completely without a CA.

I really wish we can get browser (and other client)-support for this soon, that would be such an improvement.The only 'applications' we currently have that supports fingerprints in DNS are some implementaitions of IPSEC and SSH.

Even Dan Kaminsky would probably agree to that. Especially if it wasn't based on ASN.1 like current SSL-certs.

I really hate the the whole structure of how the whole CA-business work and how SSL-certs are constructed, it's a big mess.

This is probably more of a classic case of unrealistic deadlines imposed on Gov't agencies/IT contractors by Gov't security desk jockies and/or congressmen without a clue. I'm sure the infrastructure is convoluted to begin with and I'm sure whatever planning testing was probably rushed. On top of that, I've never know *anything* in the government to 1) rarely meet a deadline on time, 2) accomplish a task on time without an exorbitant amount of hiccups to deal with, or 3) be successful without being stran

Sure, it's always good to implement updates that improve network/computer security... but let's face it. These deadlines are put in place primarily to ensure people actually pay attention and do the update in a reasonable amount of time. It's not like govt. had inside information that right after Dec. 31, 2009 - hackers were going to go crazy trying to exploit this DNS issue, so that was the day it really NEEDED to be implemented by, across the board.

Maybe I'm just in a sour mood right now with this stuff in general? But lately, I sense an ever-increasing amount of importance being placed on every little security patch or change, when it's just not really warranted. It seems really self-serving to those who work in the field of "computer security", because it makes a bunch of extra billable work for them - and they get to scare more people into paying them to secure things for them.

I mean, just this morning, I came into work and checked my mail, and what do I see? People on C-Net asking questions about if they should just "quit using Internet Explorer, given the recent security exploits". (Umm, let's see here.... You successfully used the thing ever since probably when? At least back in 2001 or 2002, right? And theoretically at least, it's "safer" now than EVER before, since Microsoft has been patching and upgrading the thing that whole time. So why would you suddenly determine NOW that it's just too unsafe to use again??)

And later today, I've got to waste my afternoon ensuring "PCI Compliance" because my workplace accepts credit cards once in a while, processed via an Internet-based card processing service. We don't even store *any* of the card data here, on either our systems or on paper. They just punch the stuff into the web site to do the processing, and let the processor keep the data. But *still*, simply because we do it, we have to have monthly "penetration testing" done against our firewall's IP address (among other requirements), and the stupid test claims I "fail" right now, due to issues that hardly matter in reality. (EG. It's complaining about unpatched issues with the Outlook Web Access part of Exchange, even though nobody even has access to use OWA in our company except me, as sysadmin -- and again, I'm finding it quite the stretch to see how someone hacking OWA here would magically obtain customer credit card info, given how we operate here?)

Maybe not you, but what about the guy down the road?
Making special exceptions just because you do X Y or Z, or don't do A B or C does not make sense. Good rules always err towards over-protection.
Not to mention the fact that the information is probably cached locally, and how does anyone outside your business know what you do and do not do with OWA or anything else? Or what you might do in three months when you decide to switch services.

Or better yet sneak into OWA and impersonate you to have others make changes elsewhere (disable a firewall or allow traffic) or even send critical data allowing $badguy to access more pertinent resources and information. What company do you work for again?

dig +dnssec @nameserver domain.xx SOA. If you get the SOA, you have a signature.Thendig +dnssec @nameserver domain.xx DS to see if you have a DS record.Thendig +dnssec @publicvalidatingserver domain.xx to see if the Chain-of-Trust is established.

So does this show a lack of government IT ability. Or is it more representative of the general inertia of government. I would worry more about the former. Where the government is exposing itself to the wilds of the internet without the ability to protect itself.

DNSSEC still has some serious problems. EG, in our preliminary analysis, a shockingly large number of Netalyzr users are behind DNS resolvers that can't handle fragmented traffic. Yet a large number are behind resolvers that do request DNSSEC data.

Since DNSSEC replies are often large (and can easily be over the 1500B response limit), turning on DNSSEC could very well mysteriously slow down DNS by causing large timeouts as the UDP reply fails to arrive and the DNS resolver, after a long timeout, then resorts to a TCP connection, even when the signatures are not validated, simply because there are a lot of resolvers that request DNSSEC but actually can't handle large replies.

DNS curve is designed to use small UDP packets. And it's more secure because it encrypts the packets' contents. But I guess that deep packet inspection folks won't allow that.

DNSSEC doesn't protect against recursive resolvers. I can set up a malicious resolver at my ISP which will just strip the DNSSEC records, not a problem. End user software still must validate the signatures.

DNSCurve is an elegant and efficient idea, and most importantly, it would be easily deployable--requiring minimal changes to infrastructure, and no cooperation from end users or support in end devices. The only obstacle that I am aware of, is that no implementation exists. (Which is a problem...)

It does not provide end-end trust, but it is close enough in most cases, and you can always run your own local DNSCurve forwarder if you need the extra guarantee.

Off Topic: I just tried the netalyzr with some interesting results. When I run it under Firefox 3.6 I get terrible results for HTTP caching. Of note is that the "diretly and explicitly" request tests for strongly and weekly uncachable data fail. When I run it under Chrome I get the expected results of no indication of an HTTP cache. So I suspect Firefox may be interfering with the HTTP caching tests.

I would like to suggest another port test, for port 6667, the default port for Internet Relay Chat. Since man

I am the DNS admin of a federal agency. We signed two of our domains, and twice had.gov delete the keys that allowed the domains to be trusted. We then got the run-around and were lied to by the.gov admin. My management and I are now afraid to make any further progress implementing DNSSEC because.gov has made so many mistakes. It is better to be unsigned than to be signed and have the trust keys be incorrect.

Additionally, the tools to implement DNSSEC are non-trivial. A federal agency or Fortune 500 can afford to buy a Secure64 Signer. Looking forward to when I want to sign my personal domains (in.org and.com), the tools have to become much simpler and much more automated.

I manage a.gov domain for a non-federal entity. Last year I pursued DNSSEC and hosted DNS to improve availability and diversity over our on-premise DNS. Windows DNS and BIND seemed okay for DNSSEC secondaries, but signing and key rollover are high-maintenance. Maybe in the near future that will change. There are appliances I could buy for $10-20k to manage master zones and do DNSSEC, but they were out of budget. I worked with a hosted provider (dynect) for DNSSEC singing with.GOV, but that turned out to be out of budget too. So eventually I just settled on dnsmadeeasy for nominal cost, with anticipation that they'll support DNSSEC sometime in mid-2010. Basically DNSSEC for the masses doesn't seem to be there yet.

IMHO, the reason this isn't done yet is because of the org structure. OMB is responsible for administrative oversight of this type of stuff, but each department don't actually work for them obviously.So it could be analagous to the corporate IT department sending an email to each department lead (sales, production) telling them to install certain patches to their desktop PC.

Yeah sure, the IT department has the right to give direction because the common CEO delegated that responsibility to them, but when pr

The initial RFC 2065 was published by the IETF in 1997, and initial attempts to implement that specification led to a revised (and believed fully workable) specification in 1999 as IETF RFC 2535. Plans were made to deploy DNSSEC based on RFC 2535.

Oh well, "netbuzz" and KDawson are probably too young to know any better:-)

The Feds spent the 90s trying to block public use of encryption anywhere in the world, but especially in the US. The excuse they used was that it would weaken their ability to eavesdrop on Commies (not that there was still a Soviet Union around by then), but they were able to interfere with the development and release of a lot of open-source software by claiming that releasing it on a public server would be export and therefore covered by the ITAR munitions export laws. They even withheld approval for "bo