Subject: Rants on auth denial

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Mar 2005 14:21:36 -0500

I called a friend and ranted for a few minutes on the topic of 
authenticated denial.  Because of time constraints, it was good to 
get it out of my system, albeit in a way only one other could hear.

In this message I'll sketch out the points I made, if I can recall 
them...this is more rant than discussion fodder or a set of 
conclusions.  It' all IMHO.

1) On-line signing is a non-starter for performance reasons.  DDoS - 
there are many ways to filter out suspect packets and dump them on 
the floor.  However, it is hard to profile bad DNS packets, whose 
intent is to incur on-line signing of a negative answer.

Once exposed to packets generated by DDos (whether or not on-line 
signing is done), the only way a server is to survive is to be able 
to dispatch the packets faster than they arrive.  (Think 
Queuing/Markov theory, distribution of inter-arrival times and 
service times, probability of there being 0 waiters in the queue.) 
Routers can work at wire speed plus, and simple lookup has a chance 
too.  But I'm afraid crypto is out of the question.

2) On-line signing is a non-starter for key management issues.  Have 
one key for all servers?  The problem is that one compromised server 
compromises all.  One key per server?  Then my RRSet will be large. 
Want a different key for the off-line signing?  Can't indicate that 
in DNSSEC, we did try that once - maybe we could make it work this 
time, with a protocol change.

3) Making simplifying assumptions about server layout restricts 
operational flexibility.  I should be able to get a slave machine 
from someone without having to give them secrets that could sign my 
zone.  (TSIG is okay, it can't sign the zone.)  I should be able to 
deploy machines based on demand - both queries per second and latency 
- without worrying about having to scale or compromise key management 
practices.

4) I really think that pre-computing the answers, as NSEC does, is a 
bigger asset than we've realized.  It is what allows us to not fear 
DDoS as much.  It also removes the problems of key management.

5) Why is zone walking an issue?  I don't buy privacy as the 
motivation.  I don't mean to argue this in this venue, but I see that 
you can get the gTLD zone files pretty easily.  I don't see a lot of 
outcry over abuses of those zones with this availability.

I don't mean to aver that this is a solid rebuttal to those concerned 
about privacy.  But as a naive (certainly in the way of privacy and 
the law) person, I don't see "it."  Perhaps ICANN (for the gTLDs) is 
a more appropriate venue to argue this.

6) I don't think that zone walking is that great a deal for the 
registries. Unless the registry just doesn't want the list of 
registrants known.  For a registry's DNS, I am not sold that zone 
walk traffic will be significantly noticeable buried with all the 
other DNS nuisance traffic.

7) However I do think there is a zone walking issue in other places. 
For instance:

7a) I want to put my X509 certificates for my employees on-line.  Yet 
I mark the company phone book "proprietary and confidential."

7b) One of the advantages of IPv6 addresses are that they are sparse. 
This makes randomly choosing an target address less useful than in 
IPv4.  If I can zone walk the IPv6 reverse tree (if it exists, it 
might if we want opportunistic encryption, etc.), the sparseness 
advantage disappears.  What about RFID?

As you might see, there are future uses for DNS and DNSSEC that may 
open up the problem space.

8) Choosing one approach that is appropriate for only those who care 
"now" is myopic.  We can't survive with different camps operating a 
common resource like DNS in different ways - fragmentation is bad.

9) We have to remember that any client-server protocol has to keep in 
mind that there are two sets of semantics.  The server-side and 
client-side can be different.  I say this as background to the issue 
of whether H(name) is a problem or not.  I don't think it's that big 
a deal.  However, H(name) has to somehow avoid flatting a zone's 
(sub)tree - and we can't assume that only one-label zones will use an 
alt-NSEC.

10) DNSSEC lacks a really cool feature - the ability to upgrade your 
security without making you less secure.  E.g., I stipulate that my 
zone are only signed with a super safe crypto algorithm.  If super 
safe isn't super available, then the majority of the world downgrades 
me to unsigned (with respect to any popular crypto algorithm). I 
mention this because if a zone elects to use some non-NSEC approach 
in place of NSEC, they appear improperly (or not at all) secure.

My conclusion is that someone (not me, I'm busy now with EPP and 
DNSSEC, etc.) needs to work out a way to make per-label hashing work. 
I think that this is more promising than on-line signing approaches. 
I think that this is also more promising than hashing a whole name. 
After all, it's not the tree structure we want to hide, but the label 
identities.

Can this be done without a protocol change?  Probably not.  I'm not 
calling for a halt to the DNSSECbis documents, etc., but I still 
haven't seen the light on how we can overcome what's in #10.  Even 
with a transition mechanism in place.

It's been a while since I've ranted on this, see this message around 
the last time I thought much on this (near the IETF in San Diego):

http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01406.html

My opinion on the option I label 2b2 may be different because of #9 
above - we don't need to create a name space for the hashes.  The 
client just needs to know how to hash what it has (the labels in the 
QNAME) in the same way as the server did to generate the response. 
The server does need to have a list of the hashes for all the 
labels/names in the zone, but they don't need to be tied to the tree. 
So what if H(label).example is the same as label2.example.?  I don't 
see that as a problem.

The approach to pre-computed responses approaches is to convince the 
client that the server executed RFC 1034, 4.3.2 (as amended) 
correctly.  That's what we need to accomplish.  NSEC does this now, 
but allows enumeration.  One-way hashes theoretically can stop this.

There is one item I'd challenge anyone thinking about all this ... 
say something about troubleshooting.  How can an operator verify that 
the responses being given are correct and not the result of a bad 
floating point accelerator or buggy cryptolibrary?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Mar 2005 16:23:58 -0500

>i thought this list was about the protocol, and that as stewards of the dns
>protocol it was our job to make it useful for the entire community including
>those who come after us.  let's not just "cash in" and try to turn dns into
>something that's just-for-those-in-the-know.

I fear my words were misunderstood.

Having seen protocols gain momentum over time, the eternal question 
is "how do we get the non-believers in the tent faster?"  Until they 
are in, we are just wasting time preaching to the converted.  This is 
a rhetorical question, because if we knew how to lure in the 
unsuspecting stake holders, we'd be luring now.

>and yet, had we involved nominet et al earlier on, then we would've known
>that zone walking wasn't an acceptable tradeoff to get authenticated denial.
>was it nominet's fault for not paying attention to us, or our fault for not
>paying attention to them?  trick question!  it doesn't matter whose fault it
>was, all that matters is we have a nondeployable protocol.  ouch!  "when in
>a hole, the first thing you should do is stop digging."

Exactly what I've been saying, or trying to.