Determination of the need

What drove the work? 

[Surely this includes the demonstrations of cache poisoning by Steve Bellovin and Tsutomu Shimomura in the early 1990s and the similar work by Dan Kaminsky in 2008, but it may include much other activity.]

The earliest security problem with the DNS was the independence of the inverse mapping tree from the forward mapping tree.  This problem — known to the CSRG at U.C. Berkeley by 1989 — was especially serious because rlogin and rsh used name-based authentication.  Specifically, rshd and rlogind looked up the hostname from the IP address and believed it.  Since the reverse tree is under control of the remote network administrator, a corrupt (or corrupted) site could point to a trusted name.  Berkeley’s fix was to do the reverse check: query the returned name and see if it pointed to the actual addresses.  But replies to both types of queries could be spoofed by DNS cache contamination.  Cache contamination attacks were found independently by Steve Bellovin (then of AT&T Bell Labs) and Tsutomu Shimomura.  Bellovin’s paper, originally written in late 1990, described a number of forms of cache contamination attack.  He sent a slightly later version of his paper to CERT and had a number of meetings in Washington with Shimomura and assorted CERT and government personnel.  No obvious fix was seen.  It was fairly obvious that a digital signature-based fix to the DNS would be a good idea, but for a number of reasons — the CPU cost, packet size issues, the RSA patent, export controls on cryptography, and the difficulty of changing the protocol — this was not pursued at the time.  Bellovin’s paper advocated using cryptographic authentication for rlogin/rsh connections.

Concern over the problem — including, specifically, leaks or rediscovery of the attack — continued for several years.  Occasionally, there were public postings that seemed close.  In early 1995, Bellovin found a copy of his paper on a (convicted) hacker’s public FTP repository.  There was obviously no longer any point to keeping it secret from the good guys; it was submitted to (and accepted at) the 1995 Usenix Security Symposium as “Using the Domain Name System for System Break-ins“.  A companion paper by Paul Vixie, “DNS and BIND Security Issues“, described a number of ways in which BIND was hardened, including randomized query sequence numbers.

The need for a better fix remained clear.  A National Academies study with Bellovin and Steve Crocker on the committee, Trust in Cyberspace(National Academies Press, 1999, Fred Schneider, ed.) described the DNS as one of two crucial, central vulnerable areas in the Internet.  The 2003 National Strategy to Secure Cyberspace repeated the warning, and noted that IETF working groups were working on the issue.  Both documents appeared after publication of the first RFC on DNSSEC, RFC 2065, “Domain Name System Security Extensions”, (January 1997, Donald Eastlake 3rd and Charles Kaufman).

Technical design

What were the key design goals and how were they addressed.  What were the alternatives?

Government planning

Key steps inside the U.S.G. and other governments, including both funding for R&D and organizational initiatives such as FISMA and the OMB memo.

Implementation and testing cycles

Including bake-offs and other field tests  (Also see below.  We leave it to you to decide whether a meeting belongs here or below.)

Public and policy awareness events and activities

Controversies

There were controversies along the way — what was the right way to do things, whether it was appropriate, or even still needed.

Friction in Deployment

Even once agreed, DNSSEC (like many general infrastructure technologies) has had some friction in its path.

Inertia – One of the key barriers to overcome in DNSSEC deployment was industry inertia (resistance to change).  This was manifested by various pieces if F.U.D (fear, uncertainty and doubt) that questioned the need for such an upgrade when the current technologies would do just fine.  It wasn’t until the Kaminski bug was made public (coincidentally right after .ORG RSTEP was approved) that the overall inertia was shaken a bit.  We cannot always guarantee that that the presumptions behind an efforts would be so readily proven right by a discovery or worse yet a catastrophe .

Business case – Hand in hand perhaps with the Inertia above, was the need for a business case for deployment.  The early adopters were undertaking the effort because “it is the right thing to do” but the early and mass majority, waited for a business case to prove that the implementation would be worthwhile (i.e. the costs would be outweighed by the new opportunities, whether it be in differentiation from competitors or in actual new services that would bring in direct revenue).  Part of the business case which was very hard to quantify was the current cost of DNS Cache poisoning, traffic hijacking etc, because many companies who had been a victim of such crimes were unwilling to divulge the fact or the details for fear of negatively impacting their brand.  I am not sure this will change dramatically, but some way to quantify the costs of stating “as is” is needed to be able to address the critics who claim that the current system is just fine (perhaps with a few minor tweaks).  It is the mentality of “if it ain’t broke don’t fix it”.  So how to show and quantify as much as possible that the current system is not sustainable as is.

Vendor View

The view from various vendors, both hardware and software.

An industry wide effort such as this, required immense collaboration and coordination across a chain of suppliers, vendors and service providers.  Often times, this required that the traditional competitive urges to keep information strictly within one’s own boundary be loosened for the greater good and faster adoption.  A  trusted and neutral 3rd party to coordinate and encourage the collaboration was one of the ways we could have achieved that, and the DNSSEC Coalition is an example, as are many others.

Specific, focused pieces

The design of the key ceremony for the signing of the root surely deserves a chapter, for example.  The implementation in each of the early TLDs is also worth one or more separate stories.  The Swedish effort spanned a several years and involved everything from technical development to policy development.  The implementation in Namibia was a much lighter weight project with its own interesting flavor.

What Else?

Meetings

Bake-offs, design meetings, interactions with other organizations, etc.  Who was there, where was it and when did it take place?  What happened, pro or con?

Vignettes

Specific moments or episodes that capture something memorable.  These need not be critical to the technical design or deployment.  They might just be humorous, fun or otherwise part of the human experience.

Decisions

Quite a few decisions have been made along the way.  Can we identify and document these?  What alternatives existed?  Why was the decision made the way that it was?  (Some of these belong better under the larger “themes” list above.)

Questions

What would you like to know that you don’t know?  What would you like to see documented that isn’t already?

We may be able to find someone to curate a list of questions so we can discharge them when we’ve gotten the answers.  (SDC: “Theanswers”??  No such thing!  One person will write what he thinks is the answer and the next person will augment, argue or contradict.  That’s a good thing.  In this context, I have in mind discharging the question as soon as there’s an answered written down that seems to be a sensible response to the question.  Since the whole wiki is open for editing at any time, there’s always room to accommodate further contributions.)

People

Who has contributed to DNSSEC over the past twenty years?  Let’s use this section as a way of asking each person to contribute to this history.  (In a separate section, perhaps to be added as a “theme,” we can record the contributions of each person.  The purpose here is to reach out to each individual and ask for his or her contribution.

We can start with the list of names ISOC has been collecting for the recognition at the IESG Plenary, Wednesday, July 28, 2010 in Maastricht, NL.

Timeline

There should be a timeline where we can list all the articles, meetings, conferences, draft publications, approvals and rejections and other events for which we can provide a date and a source.

To-Do

Any other work items to be discharged not covered above.