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

Roland van Rijswijk roland.vanrijswijk at surfnet.nl
Thu Sep 10 09:45:16 UTC 2009


Hi Roy,

Roy Arends wrote:
> 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.

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.

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?

> 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.

Cheers,

Roland

-- 
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl



More information about the Opendnssec-develop mailing list