DNSSEC and alternatives
Edward Lewis <Ed.Lewis@neustar.biz> Tue, 12 August 2008 22:52 UTC
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5823E3A68A4; Tue, 12 Aug 2008 15:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.038
X-Spam-Level:
X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZfEV4AFdEKz; Tue, 12 Aug 2008 15:52:41 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 123813A67DA; Tue, 12 Aug 2008 15:52:41 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KT2aM-0004r1-Sx for namedroppers-data@psg.com; Tue, 12 Aug 2008 22:43:26 +0000
Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Ed.Lewis@neustar.biz>) id 1KT2aI-0004qW-S2 for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 22:43:24 +0000
Received: from [192.168.7.242] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7CMhHwr089644; Tue, 12 Aug 2008 18:43:18 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06240801c4c76ecac016@[192.168.7.242]>
Date: Tue, 12 Aug 2008 15:43:15 -0700
To: namedroppers@ops.ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: DNSSEC and alternatives
Cc: ed.lewis@neustar.biz
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
I've partly read the threads on the Kaminsky "bug" and how DNSSEC is either the savior or, possibly in alliance with the bug, devil incarnate. First, to those that believe DNSSEC is an ugly pig, an ugly hack, I say you are wrong. DNSSEC was carefully designed to protect the DNS from the threats of cache poisoning, in general, against the spoofing of records between an authoritative server and anything doing the asking. Second to those that are skeptical of deploying DNSSEC, I say you are right. Even if DNSSEC is good technology, that doesn't mean it should be pressed into service. And to those of you who think you can build a "better mousetrap" I encourage you. But is isn't a race against DNSSEC, it's a race against the vulnerabilities in DNS. And remember - if the solution comes to mind easily, someone else before you probably has already thought it and tried it, so don't be disappointed if everyone else is skeptical of the new mousetrap. The problem with DNSSEC is that it has no problems. If it had a defect that prevented its adoption, then there would be something to engineer. The problem with DNSSEC is not it, but that the situation for which it was designed doesn't need it badly enough to employ it. --------------------- Each part of the DNSSEC design was carefully considered. There were many design choices made, many alternate solutions tossed aside. The current definition is the third incarnation of the protocol to be defined in RFCs. In about 2004 there was a push that culminated in the NSEC3 RFC. At that time I posted a message going over the design decisions that gave us the NSEC record. (See http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01406.html) Read that message to see the conscious design decision process. We had to give something up to eliminate zone enumeration to arrive at what is now called NSEC3. DNSSEC is not the problem. It is what it is. It is a solution to the problem of spoofed data. It values completeness in security, compatibility with operations, at the cost of having to maintain a key infrastructure. For those that get hung up on the off-line, air-gapped key, that is a vestige of the time the Security Area managed the development of the protocol (DNSSEC WG days), it really isn't important at all to operations. Personally I think and have always thought it was overkill. DNSSEC has taken time, a long time, to develop. Why is this usually cast as a negative comment? The time spent to generate the extensions is a sign of the careful consideration that went into it. The reason for three iterations is that we workshopped the technology over and over and rethought where it stunk. At least it was never rushed into service. For all the platitudes I am laying at the feet of DNSSEC, my recent presentations have been anti-DNSSEC. There are presentations at APTLD in February and a CENTR meeting floating around which I won't post the URL for here. My anti-DNSSEC sentiment is not about the technology, my anti-ness is about whether the problems it solves are important enough to solve at that cost or whether there is a cheaper (less op-ex) means to attain the same protection. Or, extending the last, cheaper while attaining a sufficient but lesser level (sliding scale) of protection. I've witnessed the DNSSEC deployment process from its beginning (with the publishing of RFC 2065) to now, from the first meeting at IETF 41 where the funding for BIND 9 began to appear. (Doing the math, IETF 72 - IETF 41 = 31, 31/(3/year) = 10.333333333 years. More than a decade now.) I was there when the process consisted of workshops, tutorials, code fixes, protocol fixes, supplemental documentation, tools, more additions, rewrites, etc. All of this succeeded in developing a workable extension to DNS, compatible with the underlying protocol but still a boatload of operational work. Perhaps in order to understand DNSSEC you have to join the "groupthink" mind-meld. And that would be a problem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- DNSSEC and alternatives Edward Lewis