Bind and ZSK-Rollovers: Changing salt automatically?

Carsten Strotmann cas at strotmann.de
Fri Jul 25 16:15:56 UTC 2014


Hi Tony,

Tony Finch <dot at dotat.at> writes:

> Carsten Strotmann <cas at strotmann.de> wrote:
>>
>> I do not understand how the NSEC3 hash can be defeated by an
>> attacker. Could you give a link to additional information or could you
>> explain the issue with NSEC3 salt in other words?
>
> http://www.vs.uni-due.de/personal/wander/20130512_NSEC3_Hash_Breaking/
>

thanks for the link, the data in this presentation is in-line with my
knowledge on NSEC3 hash breaking.

Slide 7
-----(snip)-----
Rainbow tables --- no plans
(won't work once everybody starts changing the salt regularly)
-----(snip)-----

I can imagine an attacker to store the NSEC3 chain (a snapshot) and
hash-break the names in the zone based on that snapshot, ignoring the
changes that occur in the signed zone by changing the salt.

This will allow the attacker to enumerate the zone based on the NSEC3
chain snapshot. The attacker will learn the domain names of the records
in the zone at one moment in time. It may not be the current version of
the zone. NSEC3 hash-breaking, as I understand, will not allow the
attacker to monitor changes in the zone is a timely fashion (records
added, records removed).

from the slides:
-----(snip)------
     Limited feasiblity
        9 characters: ~1 week
        10 characters: ~37 weeks
-----(snip)------

My understanding is, to break NSEC3, the full FQDN needs to be hashed
(for each test). For FQDN > 10 chars, the amount of work increases even
more.

Markov-Chains help with the hash-breaking *if* the domain names are
taken from a natural language (and not, for example, random alphanumeric
identifiers).

NSEC3 cannot prevent zone enumeration, it can only make it harder. How
hard, that depend on the NSEC3 parameters. 

Changing the salt can prevent an attacker from learning changes in an
NSEC3 signed zone "early after the change" (again, how early depends on
the parameters, but from what I see it should be in the range of weeks,
not days).

Without changing the salt, the attacker could build a rainbow table, and
with the help of a rainbow table, changes to the zone can be tracked
much quicker.

>From that perspective, I would argue that changing the salt *could* be
useful, but the DNS operator needs to know what to protect.

For many zones, NSEC3-signing and changing the salt is not worth the
effort (e.g. NSEC is sufficient).

NSEC3 can certainly not keep the domain names in a zone secret for all
times.

DNS data on authoritative servers is there to be queries, anyone can
query, enumerating a zone is a matter of time with or without NSEC3.

It would be interesting to know the difference in effort between
hash-breaking NSEC3 vs. intelligently discover a zone by the use of
sending queries (using tools like "dnsmap"
http://code.google.com/p/dnsmap/). Has anyone seen work in that area?

-- 
Carsten Strotmann
Email: cas at strotmann.de
Blog: strotmann.de


More information about the bind-users mailing list