Subject: Re: number games. (really NSEC2 vs dictionary attacks)

From: "Jay Daley" <[email-masked]>
Date: Thu, 3 Jun 2004 10:00:18 +0100

Don

don wrote on 03/06/2004 09:30:50:

> What I am saying is that walking an NSEC2 chain is still useful to the
> sorts of people we've been denying AXFRs to.  The most obvious, but not
> the only, use for the chain is a dictionary attack -- you can easily
> get 50-80% of names in a typical TLD zone via a straight dictionary
> attack, given a local copy of the complete NSEC2 chain and surprisingly
> little money's worth of compute power.

I don't have any analysis to back this up but I doubt very much if any 
dictionary attack can get anything like the percentages you quote, 
probably much less than 50%.  Once most of the single word DNs have gone 
most people fall back to double word DNs  (e.g.  don-systems.co.uk) or 
other pairings (ds-systems.co.uk) and the variety of ways in which this is 
done increases the search scope enormously.  The susceptibility of a TLD 
zone to dictionary attack may well be inversely proportional to its size.

Jay

--
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: [email-masked]
Date: Thu, 3 Jun 2004 12:49:42 +0200 (CEST)

> zone to dictionary attack may well be inversely proportional to its size.

Okay, I did a small proof of concept test.

I took an arbitrary european TLD zone from november 2003.

Number of registrations under TLD: 169209
Number of unique characters in label: 37
Bruteforce until 7 characters: 60153 hits (36%)

Dictionary attack on the left 109056 labels:

Wordlist of 3M words matched in the following order:

word, %n$word, %n-$word, %n%n-$word, %n%n%n-$word, etc.

Where %n is [0--9]

This gets 80292 of the leftover 109056 labels

So in total I get about 83%.

Roy

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 3 Jun 2004 09:26:16 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]

> >
> > I also have a question about the salt field in the original
> spec.  I still
> > am not sure it is useful.  A determined attacker will just take the salt
> > value anyway and use that.  Why not just have the hash be the FQDN?  For
> > example:  Hash(www.example.com).example.com.
>
> The salt value is a protection against pre-hashing. If you could prehash
> your dictionary, searching for collisions would be very fast.
>

But that will only slow them down - a bit.  Attackers will just do it in
real time, and eventually will still be able to do it.  The names remain the
same, just the tag in front of it changes.  They just need to stop and get
the new salt whenever it is rolled over.  The salt value becomes just
another knob that admins need to worry about and most will do "whatever the
default tool does".

I'm not totally against adding the field.  I think it would work, but
considering how static most DNS names are, I don't know if it will help DNS
as it does in other uses.

Scott

---

From: Ben Laurie <[email-masked]>
Date: Thu, 03 Jun 2004 17:29:34 +0100

> as it does in other uses.

That doesn't matter - they have to run the _whole_ dictionary each time 
to get the new names.

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: "Scott Rose" <[email-masked]>
Date: Thu, 3 Jun 2004 12:57:56 -0400

>
> > Mainly I'm thinking of ways to reduce the need for the NSECINFO
> RR and move
> > the remaining fields (hash algo and iterations) into the NSEC2 RR.
>
> I forgot to mention this last time around. So, if we move the info into
> NSEC2, it must be the same for the whole zone. Therefore, although the
> signature must be over the complete record, the server only needs to
> store _one_ copy of the redundant data, and insert it when sending the
> NSEC2s. Does this reduce your desire to eliminate NSECINFO data?
>

I'm not dead set against it, so I can accept it.  I'm just wondering if it
is better to have everything in the NSEC to avoid larger responses.  It is a
question whether 8 more bytes in each NSEC2 RR would mean a smaller response
vs. a whole NSECINFO RR and covering RRSIG.  I don't know if it makes sense
to optimize zone database size at the expense of response size.

And the complexity that comes with having another RR for storing some
information about other RR types.

Scott