[Opendnssec-develop] getting rid of HSM callsfrom the communicator
roy at nominet.org.uk
Thu Sep 10 10:01:05 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
> >> think, because it would make a dictionary attack on all 'default'
> >> OpenDNSSEC installations more feasible.
> > This is false.
> Not necessarily true, since all zones will have similar records in them
> like 'www', 'smtp', 'ns', 'mail', etc., right?
> > 3) The dictionary build for surfnet.nl is completely useless for
> > openfortress.nl, eventhough both use the _exact_ same salt.
> What if the above holds and we have remarkably similar structures? I
> have a whole host of domains that are set up using a template containing
> well known regards.
If it results in remarkably similar structures, the hash function is
broken, as each pre-image will be unique per fully qualified domain name.
Also the zone structure will not be influenced by the salt.
> This - of course - doesn't hold if the FQDN is the input for the hash,
> but I haven't checked that, is that the case?
That is the case
> > 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
> >> generating new salts for all changes, but let's at least have some
> >> differentiation between OpenDNSSEC installations by applying either
> >> 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
> > be seen as a marketing loss) However, this has nothing to do with the
> > cryptography of DNSSEC.
> LOL, marketing losses are of course bad.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Opendnssec-develop