Subject: Re: WG Last Call: DNSSEC bis documents

From: Jim Reid <[email-masked]>
Date: Tue, 18 May 2004 20:08:24 +0100

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

    >> Rate limiting and intelligent firewall filtering can reduce the
    >> exposure to NSEC traversal. It should be fairly straightforward
    >> to train a name server implementation to detect these attacks
    >> too. Sure, these defences might not be much help against a
    >> well-disguised attack. But they do provide some level of
    >> protection. So there are some non-DNS means of detecting and
    >> limiting NSEC traversals that are outwith the scope of the
    >> draft.

    Ben> I believe experience tells us that the people interested in
    Ben> these attacks are highly capable of disguising them well.

So what? That doesn't make the original text any less valid.

It shouldn't come as a surprise to anyone that there are Bad People on
the internet and some of them are remarkably good at covering their
tracks.

--
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: Jim Reid <[email-masked]>
Date: Wed, 19 May 2004 14:50:50 +0100

>> I guess that I remain unconvinced.  What -registrant- data is
    >> stored in the DNS?  In most cases, -registrant- data is stored
    >> in some whois-like database.

    Ben> NSEC provides an index to whois.

If there's a problem with disclosure of whois data, fix whois. [There's
already a WG doing precisely that.] Redesigning the DNSSEC protocol to
fix a whois problem does not seem to be sensible.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 15:43:41 +0100

> fix a whois problem does not seem to be sensible.

The problem is the _combination_ of NSEC and whois.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Jim Reid <[email-masked]>
Date: Wed, 19 May 2004 15:56:42 +0100

>> still possible, hash by hash. An offline dictionary attack
    >> (remember that the NSECINFO trick does not work) does the
    >> rest. To speed things up, you could brute-force labels with
    >> length up to 5 or 6 characters.

    Ben> If we made hashes take, say, 10 ms to compute, then this
    Ben> attack would take nearly a year. This is the point, surely?

Ever heard of Moore's law? Or how about writing an M$ worm that can
harness most of the world's Windows boxes for a dictionary attack?

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 May 2004 16:19:48 +0000 (UTC)

Jim Reid <jim <at> rfc1035.com> writes:

> 
> >>>>> "Ben" == Ben Laurie <ben <at> algroup.co.uk> writes:
> 

Right.  But designing DNSSEC to not introduce new realistic attack vectors,
compared to vanilla DNS, has always appeared sensible to me.  Whois is one
example of where the new attack vector can be utilized.  Improving the whois
protocol will remove whois as an example for our discussions, but it will not
remove the traversal problem.

The alternatives to NSEC do reduce the attack vector into an offline dictionary
attack, which I believe is an acceptable risk. Especially considering that
online dictionary attacks cannot be prevented fully either.  And nobody claims
online dictionary attacks is a problem today.  Keep in mind that online
dictionary attacks are cheaper than offline dictionary attacks.

Thanks,
Simon

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 May 2004 17:23:52 +0100

[email-masked] wrote:
> On Wed, May 19, 2004 at 03:43:41PM +0100, Ben Laurie wrote:
> 	again, what registrant data is stored in the DNS?
> 	Its clearly -NOT- in the NSEC RR, based on the spec.
> 
> 	if your concern is the binding of registrant data to
> 	some lable stuck in the DNS, then the problem is not
> 	the DNS or its attendent lables, neither is it the
> 	registrant data.  The problem is the -BINDING- between
> 	these two datasets.  And that binding is not DNS related.

Then clearly it is not whois related either - so what do we fix?

---

From: Jim Reid <[email-masked]>
Date: Wed, 19 May 2004 19:06:06 +0100

>> if your concern is the binding of registrant data to some lable
    >> stuck in the DNS, then the problem is not the DNS or its
    >> attendent lables, neither is it the registrant data.  The
    >> problem is the -BINDING- between these two datasets.  And that
    >> binding is not DNS related.

    Ben> Then clearly it is not whois related either - so what do we fix?

The BINDING. Though replacing whois is also attractive.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 21 May 2004 14:33:53 +0000

> > It is my understanding that what NSEC2 tries to achieve is to make
> > enumeration no easier than it is with plain DNS. Clearly there is no
> > point in doing more than this.
> 
> Actually, I'll take that back, there may be a point in doing more, but
> there's certainly an argument that suggests that its reasonable to expect
> not to be in a worse position by virtue of switching from DNS to DNSSEC.

So, "What Once Were Vices Are Now Habits" hits it fairly close, I guess.

I hereby renew my call that someone write a BCP describing the BINDism of
rejecting AXFR based on source address or lack-of-TSIG so that this can be
called a DNS protocol feature so that DNSSEC can be called incomplete
without it.