Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Petr Špaček <[e-mail]>]

On 27. 11. 21 7:12, Viktor Dukhovni wrote:
> On Fri, Nov 26, 2021 at 12:32:19PM +0100, Petr Špaček wrote:
> 
>> Also, when we are theorizing, we can also consider that resalting
>> thwarts simple correlation: After a resalt attacker cannot tell if a set
>> of names has changed or not. With a constant salt attacker can detect
>> new and removed names by their hash. (I'm not sure it is useful
>> information without cracking the hashes.)
> 
> Actually, no.  If one has previously been mostly successful at cracking
> extant names in a zone, rehashing of a small set (much smaller than the
> full dictionary one use) of known names is rather quick.  So old names
> can be quickly identified even after a salt change.  Leaving just the
> hashes of new names.

To be clear: I was talking about attacker who does not cracked the zone. 
You are right that rehashing know names is very cheap.


> Mind you, for cracking the new names, one would still rehash the entire
> dictionary when the salt changes, the number of new names to check is
> not a scaling factor in the cost.  Just a table join.
> 
> So periodic resalting does raise the cost of ongoing tracking of a
> zone's content, if that's the sort of thing one cares enough about.
> Rarely worth it, but mostly harmless if the salt is not too long and
> rotated say on each ZSK rollover.

Plus all the mess with large zone transfers, which often can cause 
issues, especially when done in huge batches (like rotating ZSK/salt 
shared for 100 000 zones on a shared hosting.)

-- 
Petr Špaček