[Opendnssec-develop] getting rid of HSM calls from the communicator

[Roy Arends]

Jakob Schlyter wrote on 09/09/2009 11:39:38 AM:

> On 9 sep 2009, at 11.01, Jakob Schlyter wrote:
> 
> > I suggest we get rid of the only HSM call that we have in the 
> > communicator/libksm, the salt generation, and use some other random 
> > function instead. generating the salt is not critical and libhsm to 
> > this doesn't really help that much.
> 
> so I'm saying this code (now used when no HSM is found) is good enough 
> for generating the salt:
> 
>                  srand( time(0) );
>                  for (i = 0; i < 2*(policy->denial->saltlength); i++) {
>                      salt[i] = hex_chars[rand()%strlen(hex_chars)];
>                  }
> 
> remember that the salt is published in the zone and does not have to 
> be very random.

Speaking as (one of the) authors of RFC5155, the salt has one, but only 
one function: to complicate enumeration efforts that make use of 
dictionary containing hash to name mappings (like rainbow tables and the 
like). If a zone with salt X is largely enumerated and the hash to name 
mappings are stored in a dictionary, an attacker can skip those hashes 
already matched when enumerating a new version of the zone, i.e. the 
enumeration effort becomes incremental. A new salt makes the previous hash 
to name mapping obsolete. 

So far the theory, now the practise:

The drawback of changing a salt is that the entire zone needs to be 
re-hashed and re-signed. So in highly dynamic environments or when zones 
are very large, the cost of changing salt is high as well. The costs 
really are the resigning effort and distributing the entire zone again. 
With ixfr, it is even worse, as the old nsec3 chain needs to be removed, 
and the new nsec3 chain needs to be added. Which basically doubles the 
load.

In general, we'll probably see that salts are not changed regularly, if at 
all. I'm also seeing that registries which intend to deploy with NSEC3 do 
that because of the opt-out functionality, not just anti-enumeration. 

As for opendnssec, we'd need to make sure that automated re-salting is off 
by default. Preferably ship it with a default salt. It has no implication 
that the salt is the same for each opendnssec-deployment, since there is 
no overlap of names that are hashed anyway.

That said, I'm completely confident that using the systems default 
random() function is good enough. Using a HSM for that is just too much. 
Get rid of it.

Kind regards,

Roy Arends
Sr. Researcher
Nominet UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090909/2eccf26f/attachment.htm>