[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:45:16 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.
> 
> 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 
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.
> 
> LOL, marketing losses are of course bad.

:-)

Kind regards,

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