Security

In 2003, the federal government released a report titled "The National Strategy to Secure Cyberspace," offering numerous recommendations to improve overall security. One suggestion was to replace insecure Domain Name System (DNS) servers with DNS Security Extensions, or DNSSEC. Simply stated, standard DNS has a relatively open method for updating information, making it vulnerable to an attack. DNSSEC, on the other hand, marries DNS with a public key infrastructure (PKI) for authentication and digital signatures addressing this particular vulnerability.

Since the original call to arms in 2003, DNSSEC implementation remained on the backburner--that is until recently. Now federal officials are poised to implement DNSSEC across the .gov domain by the end of 2009.

Of course, I'm all for additional security and I'm a firm believer in PKI as a way to guarantee trust and reduce DNS threats. That said, I am a bit worried that the federal government may be in over its collective head here. In theory, DNSSEC is a big improvement, but I'm concerned about:

1. Implementation. From what I've learned, implementing DNSSEC is difficult to configure and deploy. Given the size of the federal network, this may be the biggest implementation of DNSSEC to date. Will DNSSEC scale? I'm sure it will but it may be a painful process requiring new software development and lots of trial-and-error on the taxpayers' dime.

2. PKI. The federal government is probably as good at PKI management as anyone, but PKI is notoriously difficult and DNSSEC is a different type of implementation. Will DNSSEC be integrated into the federal PKI architecture or remain separate? Will there be a master PKI implementation for DNSSEC and another independent PKI for an additional federal initiative to secure the Border Gateway Protocol (BGP)? My fear is a complex web of unconnected expensive federal PKI architectures throughout Washington.

3. Security. Implemented incorrectly, DNSSEC can expose DNS Zone data, which is normally kept confidential. And DNSSEC is not immune to its own vulnerabilities. Recently, the Internet System Consortium released a number of security patches specifically for DNSSEC. My point here is the DNSSEC is not a security panacea; it too can be configured incorrectly or be prone to software vulnerabilities.

No doubt, DNS is vulnerable, but the best way I've seen to address this is with dedicated DNS appliances built on a hardened operating system along with extremely good processes around emergency patching. DNSSEC does introduce additional safeguards but they seem overly costly and cumbersome to me. Ultimately, I am sure that the federal government will persevere and get DNSSEC right, but is this effort really worth it? My guess is that this project will cost tens of millions if not hundreds of millions of taxpayer dollars. Great for beltway bandits, but is this really necessary? Let me know what you think.

Thirteen days after Dan Kaminsky asked his fellow security researchers not to speculate on the details of his DNS flaw, a fellow Black Hat researcher published his own speculation, and apparently got it right.

On July 8, IOActive researcher Kaminsky disclosed a flaw in the Domain Name System (DNS), but would not provide the details until all the affected vendors had released patches and all the systems worldwide could be patched. He figured it would take about 30 days for that to happen. The 30-day mark also just happened to coincide with his speaking engagement at Black Hat in Las Vegas on August 6.

Kaminsky has worked for about 6 months with major vendors, coordinating a massive synchronized release of patches. It was an effort at responsible disclosure. However, in an interview with CNET News, Kaminsky suggested, in retrospect, he should have been more candid with more of his peers.

Those he did confide in appeared to be won over.

Writing on Monday in his blog, Halvar Flake first attacks the very idea that a security flaw such as this could be kept a secret, then proceeds to lay out what he thinks the flaw is:

"Mallory wants to poison DNS lookups on server ns.polya.com for the domain www.gmx.net. The nameserver for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244.

"Mallory begins to send bogus requests for www.ulam00001.com, www.ulam00002.com ... to ns.polya.com."

Flake's entire speculation can be found here.

In response, Dan Kaminsky wrote Monday afternoon on his blog "Patch. Today. Now. Yes, stay late," suggesting that Flake has either guessed correctly or is very close.