[Opendnssec-develop] getting rid of HSM callsfrom the communicator

[Roy Arends]

Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 09/10/2009 
10:10:37 AM:

> Having a default salt in all OpenDNSSEC installations is bad practice I
> think, because it would make a dictionary attack on all 'default'
> OpenDNSSEC installations more feasible. 

This is false.

1) The salt is publicized in the NSEC3 record.
2) If you want to deploy a dictionary attack on surfnet.nl's zone you'd 
have to build the dictionary first, regardless of salting.
3) The dictionary build for surfnet.nl is completely useless for 
openfortress.nl, eventhough both use the _exact_ same salt.
4) if surfnet.nl _changes_ the default salt, the dictionary built for 
surfnet.nl becomes obsolete, and a new dictionary needs to be build

Step 4 is the reason we introduced salts.

fwiw, you still haven't explained why it is 'more feasible'

> It's trivial to include the
> generation of a salt in the installation process, so why not do it? Or
> even better, and still quite simple: why not generate a per zone salt
> the first time you start signing a zone?

To be clear, the default (well, the example xml) already specifies a 
random salt, of length 8, and resalts every 100 days.

> I see your argument about having re-sign and re-hash an entire zone by
> generating new salts for all changes, but let's at least have some
> differentiation between OpenDNSSEC installations by applying either of
> the suggestion above

The only security gain we get from random-salt-per-install is that 
deployments can't be remotely identified as OpenDNSSEC. (which can also be 
seen as a marketing loss) However, this has nothing to do with the 
cryptography of DNSSEC.

Roy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090910/0efd47df/attachment.htm>