[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
zone walking and random generated names
On 12/14/2004, I sent a draft about using random generated names to do
authenticated denial of existence in DNSSEC. I received some replies about
a possible MTM attack. I still believe that using random generated names
can solve the problem of non zone walking offline generated authenticated
denial of existence. I updated the idea of random generated names to stop
the MTM attack mentioned on the list and I want to know the list opinion
about it in order to not waste resources on bad ideas. Maybe I am missing
something said in the last 10 years about random generated names.
The zone example.com. has the following data:
b.example.com. A 10.10.10.10
e.example.com. A 10.10.10.11
In DNSSECbis a NSEC RR will be created to proof non existence of
c.example.com. and non existence of RR AAAA for b.example.com.
b.example.com. NSEC e.example.com. (A RRSIG)
Using random NSEC you will create random names between each existing
domain: a.example.com. and d.example.com. for example.
Two new RRs are introduced in random NSEC: rnxd (random non exising domain
proof) and rnxrr (random non existing resource record proof):
rnxd is used to proof the non existence of a name between two following
random generated names. A hash of the FQDN of the non random generated name
between the two following random generated names is sent in the response to
prevent MTM attacks.
rnxrr is used to proof the non existence of a RR for a non random generated
name.
The following record is sent to the client to proof the non existence of
c.example.com. The resolver do a verification procedure as in DNSSECbis and
also verifies that b.example.com. is not the hash value in the rnxd RR to
prevent MTM attacks.
a.example.com. rnxd
d.example.com. f96a6ec2fb6efbe43002f4cbf124f90879424d79
The following record is sent to the client to proof the non existence of RR
AAAA for b.example.com.
b.example.com. rnxrr (A
RRSIG)
The following records will be also generated.
d.example.com. rnxd
a.example.com. eb391a1462ef3dda8fdba242cf55cdab843422bb
e.example.com. rnxrr (A RRSIG)
The idea is to use the same utility that generated the signed zones to also
generate the random names, rnxd and rnxrr records.
Using this idea, an attacker will then enumerate the random-generated names
and will obtain the hash values of the non-random generated names.
Thanks.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>