If you follow the news about information technology, you probably have heard about a new DNS vulnerability discovered by Dan Kaminsky, which is often referred to as the Kaminsky Attack. Since the DNS is a protocol of the IETF-and certainly one of the most successful IETF protocols-let’s have a look at how the IETF is dealing with the issue.
Understanding the Vulnerability
There are descriptions of the attack on the Internet. Google can find many, but the Illustrated Guide to the Kaminsky DNS Vulnerability is quite good, even if you know almost nothing about DNS. It can be found here.
Dan Kaminsky’s official talk about the vulnerability can be found on the Black Hat site.
Briefly, the Kaminsky attack allows an attacker to put incorrect data into the cache of a recursive resolver, which allows the attacker to return any answer it wants to future DNS queries for a given domain. The attack is quite clever, since almost every piece of the attack has been known for a long time. However, in this case, the pieces have been put together in a new and unexpected way.
DNS Security (Pre)History
The DNS protocol was originally designed without any security, which was not unusual for protocols designed in the early 1980s. Any protocol will likely have security problems, and this is especially true for one that was designed before security was a concern-and for one that has been in use during most of the evolution of the Internet.
The list of security problems with the DNS protocol and its implementations is long and varied, but here are a few:
- Using reverse DNS to impersonate hosts
- Software bugs (buffer overflows, bad pointer handling, and so on)
- Bad crypto (predictable sequences, forgeable signatures)
- Information leaks (exposing cache contents or authoritative data)
- Cache poisoning (putting inappropriate data into the cache)
Work on securing the DNS began in the mid-1990s.
1997: RFC 2065, adding security extensions, was published several years after work began.
1999: After early implementation, it was determined that RFC 2065 needed work, so RFC 2535 was created to fix the flaws (see Appendix B of RFC 2535 for the full list of the differences).
2005: At workshops for implementers, yet more problems were discovered, including extreme difficulty getting secretkey signing material to and from a zone parent. In response, a set of three RFCs were published with the new DNS Security Extensions (DNSSEC) standards: RFC 4033, RFC 4034, and RFC 4035. RFC 4033 was the first time the requirements for DNS security were documented!
2008: DNSSEC gave users the ability to see the entire contents of a zone, and it was by looking at signed records that read no such domain. Privacy concerns made this unacceptable to some domain operators, so a new type of DNSSEC record was created. (RFC 5155 defines the extensions.)
What appears here is the history of DNSSEC proper, but it is not the only work in the area. For example, TSIG (RFC 2845) is a way to authenticate DNS operations by using a shared secret, a procedure that has been widely deployed.
As of this writing, several top-level domains and part of the reverse tree have been secured with classic DNSSEC, as defined in RFCs 4033, 4034, and 4035. The Public Interest Registry (PIR) has announced that in 2009 it intends to sign .ORG with the RFC 5155 extensions.
Recent DNS Security Work
The IETF currently has two working groups (WGs) dedicated to DNS issues:
- The DNS Operations WG, which is an ongoing group dedicated to nonprotocol aspects of the DNS, such as DNSSEC best practices and root server recommendations
- The DNS Extensions WG, which is in theory a conventional IETF working group chartered for a specific goal, but in practice it is an ongoing group that has been active since 1999: changes to the DNS protocol, such as the DNSSEC RFCs and explanations of how wildcards work, come out of this working group.
Both groups recently have done security-related work. For example, draft-ietf-dnsop-reflectors-are-evil-06.txt has been approved for publication as best current practices, and work on DNSSEC trust anchor configuration and maintenance is going on in the dnsop working group. Refinements of the DNSSEC protocol (new hash algorithms in the wake of recently discovered weaknesses in existing hash algorithms, clarifications of DNSSEC) are being evaluated, and a draft describing how to make the DNS more resilient against forged answers (draft-ietf-dnsext-forgery-resilience-*.txt) was already being discussed before Kaminsky revealed the problems he discovered.
IETF’s Response
Until 7 August 2008, when the details were made public, there were IETF participants who had inside knowledge of the Kaminsky attack. There also were participants whose information came only from press reports or other public sources, such as by looking at patches to open-source resolvers. Initial discussions had slightly surreal qualities, as those who had in-depth knowledge of the exploit discussed the ramifications with those who could only guess.
On the dnsop list, the exploit was announced, and the follow-up mails included a study of the mathematics of the exploit (estimating how long a typical exploit would take), links to and discussions of vulnerability checkers, posts of relevant news articles (such as exploits both in labs and “in the wild”?), and links to studies of how quickly resolvers were patched into various environments.
The dnsext list is the WG whereby any changes to protocols would have to be standardized. A number of proposals on the list were discussed, as were a number of nonproposals: for instance, DJ Bernstein has an alternative to DNSSEC that was mentioned, but djb is unlikely to put it forward as an Internet draft.
Most of the proposals centred on ways to make it even more difficult for an attacker to spoof packets. Another common theme was for recursive servers to detect when someone was trying to spoof traffic and therefore, put the resolver into a mode that makes spoofs more difficult.
In the end, the dnsext WG chairs decided to set deadlines for semiformal proposals at the end of September 2008. The proposals would be discussed in October, and in November a recommended forgery resistance approach would be selected. As of the time of this writing, the process is still under way.
Current Status
Some people think the Kaminsky attack will accelerate DNSSEC adoption. The .gov domain will now be signed in 2009, and there have been rumours that the root zone will be signed soon as a result of the attack. However, no changes are expected in the DNSSEC protocols.
The dnsext WG is going to make specific suggestions for a new forgery-resistance mechanism based on the outcome of the selection process. This should help harden resolvers enough to make the Kaminsky attack unfeasible in the current Internet.
The IETF is a great organization for reviewing the details of the DNS on a technical level. A considerable amount of good information and discussion ensued as a result of the attack. It is our hope that everyone involved will benefit from the recommendations that will follow.