Like so many of the Internet protocols invented decades ago, the Domain Name
System has some serious security issues. Earlier this week in Stockholm, the Internet Society (ISOC), the Internet Engineering Task Force, and DNS experts provided a status update on DNSSEC, the secure DNS protocol designed to close a security hole in the bowels of the Internet that has been the target of exploits.
The IETF is having its summer meeting in Stockholm this week, graciously sponsored by .SE, the people in charge of the Swedish .se top level domain (TLD). That domain was one of the first TLDs in the world to deploy DNSSEC, so the stars aligned for the ISOC to steal a lunch hour on Tuesday during the busy IETF week to tell the community about the status of DNSSEC.
DNSSEC is the secure form of the Domain Name System, which has been plagued by security issues in recent years. We got to hear from DNS expert Olaf Kolkman (who also happens to chair the Internet Architecture Board, IAB) who proposed to "grow us a chicken" to get around the chicken-egg problem of implementing DNSSEC. After all, why would domain owners implement DNSSEC if ISPs and applications don't heed the extra security options, or would ISPs deploy security-aware DNS servers if domain owners don't publish secure information? Later in the discussion the chicken-egg analogy would be extended in various ways, not the least of which involved breaking the wings of the poor chick, but Kolkman ended with the picture of a proud rooster.
Much as it has with IPv6, the IETF has been working on the DNS security problem for more than a decade in the form of DNSSEC. However, there were some false starts, and only recently has DNSSEC starting to be deployed in the Internet's DNS infrastructure. Patrick Wallstr�m of .SE and Jim Galvin of the Public Interest Registry explained how they had implemented DNSSEC in the .se and .org domains, respectively.
In Sweden, the demand for secure DNS delegation surged when the extra fee was dropped, and around the same time, the Kaminsky exploit came out. .org is still in the "friend and family" period but expects to launch production DNSSEC in 2010. .net will follow in late 2010 and .com in early 2011, according to Matt Larson of Verisign.
The Domain Name System (DNS) that translates domain names into IP addresses has long been a favorite attack vector for those looking to separate unsuspecting Internet users from their data or money. Some years ago it was laughably simple to inject incorrect information in the DNS servers used by regular end-users to find the addresses belonging to the websites they want to visit. (Usually their ISP's nameservers.) Knowing that on an abstract level is one thing, but suddenly seeing porn banners decorate otherwise clean-cut websites made me much more aware of the issue several years ago.
Since then, these so-called cache poisoning attacks have been made much harder, but then Dan Kaminsky came along and showed that the DNS security model is fundamentally flawed. (Kaminsky has a one-hour slot under the title "undisclosed topic—you will be amazed" during next month's open-air technology and security conference HAR2009. That can't be good.)
So how does DNSSEC protect unsuspecting users against unwanted porn banners or worse if a top-level domain enables DNSSEC and "gets signed?" First a quick DNS refresher. The DNS is a big distributed database, where everyone manages his or her own data. All this disparate information is tied together through a hierarchical naming and delegation structure. All of this begins at the "root," which is managed by the Internet Corporation for Names and Numbers (ICANN).
In the root "zone" there are delegations to the different top level domains, such as .gr, .us, .org, and .com. Each of these in turn delegates authority over domains such as ietf.org or arstechnica.com to the respective domain holders. Those in turn populate their DNS servers with addresses. When a zone such as .org is signed, it means that it can provide cryptographic assurances about how a zone further down in the hierarchy is delegated. So if someone were to inject false information about ietf.org into random nameservers around the world, these servers can request the new DNS records that contain the cryptographic signatures from .org, and reject anything that doesn't check out.
So how does a DNS server know that the .org info is legit? A TLD zone would have to be authorized by the next higher level in the hierarchy, which is the root. However, the root isn't signed at this point. This means that anyone who wants to perform DNSSEC verification today, needs to install trust anchors for every signed zone in their DNS server. This gets tedious fast, as there is no standard way to get this information out. So Swedish ISPs perform validation for .se domains, but not necessarily for any other TLDs.
Fortunately, it looks like the root will be signed before the end of the year, so only a single trust anchor that points towards the DNS root will be necessary from then on. At that point, it becomes relatively easy for Internet service providers to start validating DNS information for domains under all TLDs and reject fraudulent information—if the domain is signed, at least. The final step is for operating systems or even applications to implement DNSSEC and perform validation locally, making the entire chain from the root to the application secure.
from http://arstechnica.com/security/2009/07/saving-us-from-forged-dns-data-an-update-on-dnssec/
System has some serious security issues. Earlier this week in Stockholm, the Internet Society (ISOC), the Internet Engineering Task Force, and DNS experts provided a status update on DNSSEC, the secure DNS protocol designed to close a security hole in the bowels of the Internet that has been the target of exploits.
The IETF is having its summer meeting in Stockholm this week, graciously sponsored by .SE, the people in charge of the Swedish .se top level domain (TLD). That domain was one of the first TLDs in the world to deploy DNSSEC, so the stars aligned for the ISOC to steal a lunch hour on Tuesday during the busy IETF week to tell the community about the status of DNSSEC.
DNSSEC is the secure form of the Domain Name System, which has been plagued by security issues in recent years. We got to hear from DNS expert Olaf Kolkman (who also happens to chair the Internet Architecture Board, IAB) who proposed to "grow us a chicken" to get around the chicken-egg problem of implementing DNSSEC. After all, why would domain owners implement DNSSEC if ISPs and applications don't heed the extra security options, or would ISPs deploy security-aware DNS servers if domain owners don't publish secure information? Later in the discussion the chicken-egg analogy would be extended in various ways, not the least of which involved breaking the wings of the poor chick, but Kolkman ended with the picture of a proud rooster.
Much as it has with IPv6, the IETF has been working on the DNS security problem for more than a decade in the form of DNSSEC. However, there were some false starts, and only recently has DNSSEC starting to be deployed in the Internet's DNS infrastructure. Patrick Wallstr�m of .SE and Jim Galvin of the Public Interest Registry explained how they had implemented DNSSEC in the .se and .org domains, respectively.
In Sweden, the demand for secure DNS delegation surged when the extra fee was dropped, and around the same time, the Kaminsky exploit came out. .org is still in the "friend and family" period but expects to launch production DNSSEC in 2010. .net will follow in late 2010 and .com in early 2011, according to Matt Larson of Verisign.
The Domain Name System (DNS) that translates domain names into IP addresses has long been a favorite attack vector for those looking to separate unsuspecting Internet users from their data or money. Some years ago it was laughably simple to inject incorrect information in the DNS servers used by regular end-users to find the addresses belonging to the websites they want to visit. (Usually their ISP's nameservers.) Knowing that on an abstract level is one thing, but suddenly seeing porn banners decorate otherwise clean-cut websites made me much more aware of the issue several years ago.
Since then, these so-called cache poisoning attacks have been made much harder, but then Dan Kaminsky came along and showed that the DNS security model is fundamentally flawed. (Kaminsky has a one-hour slot under the title "undisclosed topic—you will be amazed" during next month's open-air technology and security conference HAR2009. That can't be good.)
So how does DNSSEC protect unsuspecting users against unwanted porn banners or worse if a top-level domain enables DNSSEC and "gets signed?" First a quick DNS refresher. The DNS is a big distributed database, where everyone manages his or her own data. All this disparate information is tied together through a hierarchical naming and delegation structure. All of this begins at the "root," which is managed by the Internet Corporation for Names and Numbers (ICANN).
In the root "zone" there are delegations to the different top level domains, such as .gr, .us, .org, and .com. Each of these in turn delegates authority over domains such as ietf.org or arstechnica.com to the respective domain holders. Those in turn populate their DNS servers with addresses. When a zone such as .org is signed, it means that it can provide cryptographic assurances about how a zone further down in the hierarchy is delegated. So if someone were to inject false information about ietf.org into random nameservers around the world, these servers can request the new DNS records that contain the cryptographic signatures from .org, and reject anything that doesn't check out.
So how does a DNS server know that the .org info is legit? A TLD zone would have to be authorized by the next higher level in the hierarchy, which is the root. However, the root isn't signed at this point. This means that anyone who wants to perform DNSSEC verification today, needs to install trust anchors for every signed zone in their DNS server. This gets tedious fast, as there is no standard way to get this information out. So Swedish ISPs perform validation for .se domains, but not necessarily for any other TLDs.
Fortunately, it looks like the root will be signed before the end of the year, so only a single trust anchor that points towards the DNS root will be necessary from then on. At that point, it becomes relatively easy for Internet service providers to start validating DNS information for domains under all TLDs and reject fraudulent information—if the domain is signed, at least. The final step is for operating systems or even applications to implement DNSSEC and perform validation locally, making the entire chain from the root to the application secure.
from http://arstechnica.com/security/2009/07/saving-us-from-forged-dns-data-an-update-on-dnssec/
