<tt><font size=2>Roland van Rijswijk <roland.vanrijswijk@surfnet.nl>
wrote on 09/10/2009 10:10:37 AM:<br>
<br>
> Having a default salt in all OpenDNSSEC installations is bad practice
I<br>
> think, because it would make a dictionary attack on all 'default'<br>
> OpenDNSSEC installations more feasible. </font></tt>
<br>
<br><tt><font size=2>This is false.</font></tt>
<br>
<br><tt><font size=2>1) The salt is publicized in the NSEC3 record.</font></tt>
<br><tt><font size=2>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.</font></tt>
<br><tt><font size=2>3) The dictionary build for surfnet.nl is completely
useless for openfortress.nl, eventhough both use the _exact_ same salt.</font></tt>
<br><tt><font size=2>4) if surfnet.nl _changes_ the default salt, the dictionary
built for surfnet.nl becomes obsolete, and a new dictionary needs to be
build</font></tt>
<br>
<br><tt><font size=2>Step 4 is the reason we introduced salts.</font></tt>
<br>
<br><tt><font size=2>fwiw, you still haven't explained why it is 'more
feasible'</font></tt>
<br>
<br><tt><font size=2>> It's trivial to include the<br>
> generation of a salt in the installation process, so why not do it?
Or<br>
> even better, and still quite simple: why not generate a per zone salt<br>
> the first time you start signing a zone?</font></tt>
<br>
<br><tt><font size=2>To be clear, the default (well, the example xml) already
specifies a random salt, of length 8, and resalts every 100 days.</font></tt>
<br>
<br><tt><font size=2>> I see your argument about having re-sign and
re-hash an entire zone by<br>
> generating new salts for all changes, but let's at least have some<br>
> differentiation between OpenDNSSEC installations by applying either
of<br>
> the suggestion above</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>Roy</font></tt>