The Public Interest Registry, which manages the .org domain, announced in May 2008 plans to sign .org beginning in early 2009 and proceed with a phased deployment of DNSSec to a limited number of domains and registrars. The reason for the slow rollout is that DNSSec is uncharted territory; only a few other top-level domains--namely Mexico, Puerto Rico, and Sweden--have started using the protocol. Policy and technical issues that must be sorted out range from required software to generate and manage keys to deciding how to vet domain owners. The U.S. federal government's DNSSec initiative also is a phased rollout.
VeriSign, which runs the root servers and controls the .com and .net top-level domains, is taking a more measured approach. The company was involved in the development of DNSSec standards documents and runs test beds, so it's invested in securing DNS. However, VeriSign also has the responsibility of making sure the root servers and the top-level domains it manages are stable and available, and the sheer scale of the undertaking is daunting. Ken Silva, VeriSign's CTO, says .com contains more than 77 million active domains, and .com servers receive about 600,000 queries per second. Because DNSSec records are larger than DNS records, storage and network capacity would need to be increased to meet the new load. And capacity scaling at top-level domain servers is only one issue. All caching name servers also would have to be scaled up for storage and network capacity, as well as adding cryptographic functions to validate DNSSec records that they retrieve and forward.
Domain owners would need to manage keys and ensure DNSSec records are signed properly. An expired DNSSec key should be treated as a failure and not trusted, which will result in hosts not being able to access services. If a domain generates revenue, a failure in DNSSec could get expensive fast. These issues aren't insurmountable, but VeriSign is being cautious in approaching DNSSec, and rightly so.
UNTIL THEN, WHAT'S LEFT?
To positively identify a service, you need some way to authenticate it. SSL/Transport Layer Security is a well-understood and widely deployed protocol for providing authentication and encryption functions. The SSL protocol hasn't shown any weaknesses, even though certain implementations of SSL/TLS libraries have.
Whether SSL/TLS is an effective way to secure data moving outside your borders depends on a few factors. First, it must be applied correctly in Web applications, such as SaaS and cloud computing. A number of developers we spoke with say that, in many cases, applications that use Web services, SOAP, and REST and employ SSL/TLS don't check the authenticity or validity of the digital certificate. The reason, typically, is that the cost of downtime because of an SSL/TLS failure from an invalid or untrusted self-signed certificate is unacceptably high. Other security functions, like network firewalls, which limit who can access a Web service, and XML firewalls, which inspect Web services traffic for problems, are deemed sufficient.
We disagree. To safely use SSL/TLS as a secure protocol, certificate validity must be verified and where there are failures, the connection should be aborted until trust can be re-established. This need not be onerous. Organizations don't need to purchase digital certificates from a public certificate authority to have the certificate trusted. For now, given an application where the client population is small, running your own certificate authority and issuing certificates may be sufficient.
We say "for now" because as more IT processes rely on Web services, that position will become untenable. The brief history of Internet security shows us that attackers, from lowly miscreants to organized criminals, follow the technologies that will let them commit mayhem. We're still years away from widespread DNSSec adoption, while SSL/TLS is available now. But don't assume that cloud and SaaS providers are using SSL/TLS properly. Ask for confirmation that any application that handles sensitive data uses certificates appropriately and will safely authenticate services.
As for DNSSec, CIOs need to turn up the heat. Start pressuring operating system vendors to install DNSSec-aware software to authenticate DNSSec responses. Insist that application vendors support DNSSec so a Web browser, for example, can differentiate between a signed and unsigned DNS response. Demand that service providers support DNSSec in their name servers. Follow the various test cases and, as DNSSec moves along, consider creating your own DNSSec DNS server and signing your own zone. DNS insecurity is a problem for everyone who uses the Internet, and we all must be part of the solution.
Time To Send Out For Security Help?