Re: zone walking and random generated names

[Alex Bligh <alex@alex.org.uk>]

> Maybe
> I am missing something said in the last 10 years about random generated
> names.

I *think* what you are trying to say, is at signature time generate
a number of RR's with random labels within the zone, and use these
as boundary points for non-existence proofs. I may have misunderstood.

I am taking it that the rnxd needs to have the next (random) domain
in the record, so it is signed (and you cannot have a man in the middle
attack). In this case, there is a walkable chain of random names which
would seem to give nothing away. Each says merely "there is nothing
between R1 and R2 except the label with the hash which comes along
with the record".

That's all fine and dandy until you realize that you need to put
at least one "random" name between each existent name, as only one
name can be carried in the hash. (Of course you can put more than
one, and the intervals that contain no existing normal names can
have a hash of something outside the interval itself).

But I think this is not going to hide much of the zone.

For instance, let's assume the zone has
 secret-sausage.co.uk
 secret-squirrel.co.uk
 secret-squirrel-incorporated.co.uk
 secret-squirrel-industries.co.uk
 secret-swizzle.co.uk

then we'd have to generate something like:
 secret-sausage.co.uk
 secret-smsadg24g34gdsaf.co.uk		rnxd
 secret-squirrel.co.uk
 secret-squirrel-a1423252fb.co.uk		rnxd
 secret-squirrel-incorporated.co.uk
 secret-squirrel-incu41jhgah.co.uk	rnxd
 secret-squirrel-industries.co.uk
 secret-srweadfaskdhjasd.co.uk		rnxd
 secret-swizzle.co.uk

All the records with rnxd are visible. So the attacker gets:
 secret-smsadg24g34gdsaf.co.uk		rnxd
 secret-squirrel-a1423252fb.co.uk		rnxd
 secret-squirrel-incu41jhgah.co.uk	rnxd
 secret-srweadfaskdhjasd.co.uk		rnxd

Now I grant you we haven't got an exact enumeration there. However
a little bit of analysis based on the distance between records will
tell you how many letters you've got right.

So if I've understood this correctly, I think it would work, but
I don't see it as less disruption than NSEC3, but gives less
"hiding".

Alex

--
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/>