[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