Network News

X My Profile
View More Activity

White House Imposes New Security Mandate for Federal Agencies

The Bush administration has ordered all federal agencies to adopt new measures to shore up the security of government Web sites, setting a January 2009 deadline for implementing the changes across all dot-gov domains.

ombdns.jpg

Agencies will be required to roll out domain name system security extensions (DNSSEC), a set of security add-ons for the domain name system. DNS is a fundamental piece of the Internet infrastructure that acts as a kind of distributed Internet phone book used to route messages between computers.

The trouble with the current implementation of DNS is that it was developed and implemented in an era when the Internet was a much smaller and friendlier place, where the handful of researchers who used the system trusted one another. These days, however, cyber crooks are eager to divert Internet traffic to fraudulent or hostile sites by constantly seeking to poison the DNS records on consumer PCs and at the network level.

DNSSEC seeks to protect Internet users against forged or poisoned DNS data by digitally signing DNS requests. By checking a digital signature, the end-user (or tools built into the browser) can check to make sure that the DNS information was indeed sent by the authoritative DNS server for that domain.

The mandate, issued Friday, by the White House Office of Management and Budget, comes amid increased attacks against a pervasive security weakness recently uncovered in DNS. In June, dozens of software vendors released security updates to plug a vulnerability that lets attackers hijack large amounts of Web traffic and redirect it to fraudulent or malicious sites. However, many Internet service providers and companies responsible for maintaining portions of the Internet have yet to apply the fixes, and criminals are beginning to take advantage of the weakness. Meanwhile, new research suggests even the fix for the flaw may also be exploitable.

"The Government's reliance on the Internet to disseminate and provide access to information has increased significantly over the years, as have the risks associated with potential unauthorized use, compromise, and loss of the .gov domain space," wrote Karen Evans, administrator of the OMB's Office of E-Government and Information Technology, in a memo to agency chief information officers.

Having DNSSEC in place would make it much harder for hackers to hijack Web traffic destined for dot-gov domains. Marcus Sachs, director of the SANS Internet Storm Center, a Bethesda based group that tracks hacking trends, said DNSSEC would pave the way for more secure e-government services, particularly with private-sector companies that incorporate the government's digital signatures, such as tax preparation companies that help consumers file their returns with the IRS online.

"That way, the software you use could validate through the digital signature process that you're really filing your taxes at www.irs.gov, and not some scammer site" that has hijacked your computer or ISP's DNS records, Sachs said.

Under the timetable, the federal government will need to develop initial planning drafts by Sept. 5, 2008, and deploy DNSSEC to the top level dot-gov domain by next January. Agencies will need to have the system rolled out entirely to all second-level domains beneath dot-gov by Dec. 2009.

By Brian Krebs  |  August 27, 2008; 11:00 AM ET
Categories:  New Patches , U.S. Government  
Save & Share:  Send E-mail   Facebook   Twitter   Digg   Yahoo Buzz   Del.icio.us   StumbleUpon   Technorati   Google Buzz   Previous: Web Fraud 2.0: Thwarting Anti-Spam Defenses
Next: Report Slams U.S. Host as Major Source of Badware

Comments

In the image you attached to this post, it looks like Karen Evans, not Karen Hughes, is the name of the administrator of the Office of E-Government and Information Technology.

Posted by: William | August 27, 2008 11:53 AM | Report abuse

Hmmm, don't DNS lookups depend on a top-down path starting at the ROOT domain? What good will it do to have the .gov domain be DNSSEC enabled if it doesn't have the next level up likewise secured? Seems like the "chain of trust" is broken before it barely has begun ...

Posted by: J.F. | August 27, 2008 1:15 PM | Report abuse

Will -- Fixed. Thanks!

Posted by: Bk | August 27, 2008 1:25 PM | Report abuse

J.F.> Hmmm, don't DNS lookups depend on a top-down path starting at the ROOT domain?

DNSSEC can support trust anchors at any point in the DNS hierarchy. It's just extra work to manage them. It's similar to having the list of root servers; you maintain a list of trust anchors as a bootstrap for various points in the hierarchy. Ideally, as you suggest, there's just one anchor, for the root.

This should be a moot issue by January, because ICANN plans to sign the root zone by "late 2008":

http://www.icann.org/en/announcements/announcement-24jul08-en.htm

Bk> Marcus Sachs... "said DNSSEC would pave the way for more secure e-government services, particularly with private-sector companies that incorporate the government's digital signatures"

In other words, an important advantage of DNSSEC is that it provides a mechanism that can replace certificates for validating web sites, namely putting public keys into the DNS. Once client code is incorporated into browsers to take advantage of this, every host can use SSL (or something very much like it) without having to purchase certificates from third-party CAs such as Verisign. Essentially, the .gov registry maintainers become a CA for everything under .gov.

Posted by: antibozo | August 27, 2008 1:33 PM | Report abuse

The need for the ROOT domain to be DNSSEC enabled if there is to be anything close to the envisioned security is not just an "ideal" situation, but a MANDATORY one.

Simple example: Suppose I ask a root DNS nameserver about whitehouse.gov. Suppose further that while the .gov domain is DNSSEC enabled, the root is NOT. I get a response back from the root nameserver that says to now go to a certain .gov nameserver to get the answer about whitehouse.gov. PROBLEM: Maybe the response that I am getting back from the root nameserver has been spoofed ... and so the ".gov nameserver" that I am being directed to is actually a server that is NOT really a .gov nameserver, but is pretending to be.

You see? "Anchors" of trust are of no value ... you need an unbroken chain of trust.

Posted by: J.F. | August 27, 2008 2:35 PM | Report abuse

Only the civilian government sites will use DNSSEC? What about military sites (the dot mil domain)?

Posted by: rlguenther | August 27, 2008 2:55 PM | Report abuse

J.F.> Simple example: Suppose I ask a root DNS nameserver about whitehouse.gov. Suppose further that while the .gov domain is DNSSEC enabled, the root is NOT.

You don't understand the process. In a non-root-signed scenario, you already have the public key for .gov (perhaps along with those for the other TLD zones that are already using DNSSEC, i.e. .bg, .br, .se, .pr, and, soon, .org) preloaded in your name server configuration. You ask the root nameservers for the nameservers for .gov. If someone spoofs the NS response for .gov, lookups against the spoofed server will fail because the spoofed server doesn't have private signing keys that match your preloaded public key.

Signing the root is ideal because then there is only one trust anchor to maintain, but it is not required.

As far as the general issue of trust anchors, I suggest you take a look at your browser's CA certificate store to see how it is possible to have many trust anchors. The difference with non-root-signed DNSSEC is that each trust anchor only anchors a subtree of the DNS whole. Even with a signed root, you have at least one trust anchor, namely the root key, which also has to be preloaded into your nameserver configuration.

In addition, there is another option called lookaside validation, which hopefully won't be necessary, where one or more alternate roots are provided for DNSSEC key information. See RFC 5074 for further information.

Posted by: antibozo | August 27, 2008 3:53 PM | Report abuse

ab> "You don't understand the process. In a non-root-signed scenario..."

The DNS process is (not worrying about cached values and TTLs, to simply) to start at the ROOT domain to seek resolution of a DNS entity. The root domain responds with a REFERRAL to the next level down, the "top-level" domain. That results in a REFERRAL to the next level down. And so on, and so on, until the domain that is authoritative for the question being asked responds.

DNSSEC merely adds an authentication layer by having DNS zones signed in a way that is similar to certificate based authentication. But it depends on that chain of trust, that needs to start at the top. Any break in the chain questions the integrity of the entire process.

Posted by: J.F. | August 27, 2008 5:15 PM | Report abuse

Web Fraud 2.0: Halp!

Posted by: flipflap | August 27, 2008 5:20 PM | Report abuse

J.F.> But it depends on that chain of trust, that needs to start at the top. Any break in the chain questions the integrity of the entire process.

That's where you aren't getting it. Chains of trust start from trust anchors. Trust anchors can be embedded anywhere in the DNS tree. It is helpful, but not necessary, for there to be a trust anchor at the root.

You may wish do a little research on your own before commenting further. I suggest you start with RFC 4986:

http://www.rfc-archive.org/getrfc.php?rfc=4986

which has, for example, this statement:

"For various reasons, DNSKEY RRs or DS RRs from zones other than Root can be used by operators of security-aware resolvers as Trust Anchors."

You may also wish to read RFC 5074, as I mentioned earlier. You can find it here:

http://www.rfc-archive.org/getrfc.php?rfc=5074

which says, among other things:

"With DNSSEC, validators may expect a zone to be secure when validators have one of two things: a preconfigured trust anchor for the zone or a validated Delegation Signer (DS) record for the zone in the zone's parent (which presumes a preconfigured trust anchor for the parent or another ancestor). DLV adds a third mechanism: a validated entry in a DLV domain (which presumes a preconfigured trust anchor for the DLV domain)."

Posted by: antibozo | August 27, 2008 5:35 PM | Report abuse

Signing zones, root-anchored or not, is only part of the solution. If the resolvers don't *require* a valid signature, the utility is... quite limited. How long do we think it'll be before any ISP will deploy DNSSEC-capable resolvers, and further to configure them to refuse unsigned RR sets? And, ideally, to have *client* stub-resolvers configured that way? Do any of the resolvers currently available even support partial enforcement of DNSSEC on a per-domain basis?

Signing zones is only the beginning of a *very* long road.

Posted by: jml | August 27, 2008 10:59 PM | Report abuse

jml> If the resolvers don't *require* a valid signature, the utility is... quite limited.

It isn't up to the resolvers to require validation; it's up to the clients to request it, and for some time, I would expect most clients to fall back to traditional DNS where DNSSEC is unavailable. Presumably, browsers and the like will indicate to the end user whether DNSSEC is available for the near term. Longer term, hopefully, public keys in DNS records will replace certificates for most SSL; at that point, asking for something like https would implicitly require DNSSEC and use public keys taken directory from the DNS, falling back to x509 certificates where needed. Something like EV certs will still be needed to assert real-world identity where appropriate, e.g. with financial institutions.

Obviously the resolvers have to be *capable* of making and validating DNSSEC queries. BIND has been for a long time. Stub resolvers will certainly need additional work to be able to do validation directly on end systems. This has been low priority work because DNSSEC deployment has been so sparse. Stub resolvers especially have been low priority while we have an unsigned root because every trust anchor has to be embedded in every resolver, and maintaining dozens of trust anchors on every client system would be a major PITA. If ICANN comes through and really signs the root by the end of the year, stub resolvers can move forward in earnest. (They still might need DLV for .com and .net if Verisign digs in its heels, which won't surprise me in the least--they make a lot of money selling certs precisely because DNS is insecure.)

Yes, it's a long road, but we're finally on it now and no longer just talking about it. We should have been on this road five or six years ago. Imagine where we'd be now if we had been... we certainly wouldn't be wasting man-years trying in vain to mitigate against cache poisoning, and we might even have ubiquitous PKI and opportunistic encryption.

Posted by: antibozo | August 27, 2008 11:53 PM | Report abuse

"RFC" -- which stands for Request For Comment -- is just that, a technical working paper for implementors to consider. For DNS in particluar, many RFC ideas that once found favor, such as DNAME and A6 resource records, fell out of favor once the light of reality shined on the quirky implementations.

To try to put things back in perspective, let me quote from Dan Kaminsky [http://www.doxpara.com - "On the Flip Side"], who discovered the DNS protocol flaw that motivated the decision to attempt to jump-start DNSSEC on the .gov domain:

"First, the universal constraint on every solution is that it must cover the root servers, and the TLD’s, because they’re almost always a better target for poisoning since their position higher in the DNS heirarchy allows them to pollute any name below them. In other words, you can totally opt foo.com into whatever security system you like, but unless A.GTLD-SERVERS.NET (the server for com) is itself secure — and unless the root servers that tell you where A.GTLD-SERVERS.NET — are also included in the solution — there’s no effective security whatsoever. DNSSec, minus the DLV hack, suffers this specific issue, and so does everything else. You either need to be backward compatible all the way up the heirarchy, a trait that port randomization and some other solutions have, or you need to push code to them."

Finally, it always helps when considering some grandiose (and desperate) scheme to apply a couple of doses of common sense:

(1) A chain is only as strong as it's weakest link.

(2) If it doesn't make sense, don't believe it ... and don't do it. (Ironically, attributed to the late Ken Lay of the ENCRON debacle.)


Posted by: J.F. | August 28, 2008 12:34 AM | Report abuse

Ooops, make that "ENRON" for that last ...

Posted by: J.F. | August 28, 2008 12:36 AM | Report abuse

J.F., unfortunately, you simply don't appear to understand how the PKI in DNSSEC works. If it doesn't make sense to you, you need to keep reading it until it does. It does work, it is reliable, and using an unsigned root along with trust anchors for other points in the DNS tree introduces no vulnerability whatsover in the security of those anchored subtrees. You can quote Kaminsky all you like, but you'd do better to take the time to understand how and why it works. I've done what I can to explain it to you; if you still don't believe me, feel free to post a *specific* attack scenario and I'll be happy to explain why it fails.

Posted by: antibozo | August 28, 2008 12:50 AM | Report abuse

The comments to this entry are closed.

 
 
RSS Feed
Subscribe to The Post

© 2010 The Washington Post Company