[Opendnssec-develop] getting rid of HSM callsfrom the communicator
roy at nominet.org.uk
Thu Sep 10 09:41:09 UTC 2009
Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 09/10/2009
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Opendnssec-develop