DNSSEC and alternatives

[Edward Lewis <[e-mail]>]

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                                                [phone]
NeuStar

Never confuse activity with progress.  Activity pays more.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>