Subject: Re: rollling salt/iterations/hash

From: "Roy Arends" <[email-masked]>
Date: Wed, 4 Aug 2004 03:18:32 +0200

From: "Ben Laurie" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 04, 2004 3:55 AM
Subject: rollling salt/iterations/hash

> Sam suggested during the WG meeting that there might be an issue with
> rolling salt, iterations or hash in NSEC++, namely that the zone might
> be unprotected during such a roll. I don't understand why he thinks
> this, but let me say I don't believe it is correct. Since each NSEC++
> record contains the parameters used to generate it, when a client
> receives one as a negative response, it has everything it needs to check
> that the interval contains the hash of the request, regardless of
> whether it gets the "pre-roll" or "post-roll" version of the record (of
> course, they will almost certainly correspond to completely different
> records in the zone, but this is unimportant).

What I explained to Sam is that NSECX records (with different salts) may
collide wrt rolling salt. It is an attack vector, since an adversary is able
to deny existing, signed records (which have a post-roll NSECX) using a
pre-roll NSECX. Changing the salt alters the 'denial span'.

To avoid this, salts should (must?) only be rolled at RRSIG experation
boundaries. This is a fairly complex corner-case, since rolling the salt
means resigning as well. You definitly do not want to sign and publish
records at expiration time, but preferable a multiple TTL lifetimes before.

Note that any change in salt or iterations changes the hash for a single
name. Any changed hash introduces possible collisions between pre- and post-
roll.

Roy

--
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: Ben Laurie <[email-masked]>
Date: Wed, 04 Aug 2004 03:21:54 +0100

> pre-roll NSECX. Changing the salt alters the 'denial span'.

This is not to do with salts, since the same would be true with NSEC 
records (i.e. an unexpired NSEC can be used to deny a now existing record).

> name. Any changed hash introduces possible collisions between pre- and post-

I don't see why that would be an issue, since the recipient of a record 
always knows what the hash parameters are - the fact that two sets of 
parameters give the same hash for different names doesn't seem important 
- what am I missing? (Of course, its astronomically unlikely this will 
happen unless we choose a stupid hash).

Cheers,

Ben.

---

From: "Roy Arends" <[email-masked]>
Date: Wed, 4 Aug 2004 04:01:01 +0200

From: "Ben Laurie" <[email-masked]>
To: "Roy Arends" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 04, 2004 4:21 AM
Subject: Re: rollling salt/iterations/hash

> records (i.e. an unexpired NSEC can be used to deny a now existing
record).

Yes, it is the same.

> happen unless we choose a stupid hash).

I'm NOT talking hash collisions.

I'm talking about a collision between a post-roll hash and a span between
two canonically ordered pre-roll hashes. This collision is VERY probable.

But, as you said, it is essentially the same attack vector as with newly
added records and unexpired NSEC records.

Roy