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
Petr Špaček wrote on 2021-11-26 01:24:
...
Maybe your proposed text can be prepended/appended to the current
content of 3.2. Recommendation for validating resolvers, so we can keep
the "vendors are encouraged to continue evaluating NSEC3 iteration count
deployments" part?
if we must say
On 26. 11. 21 11:49, Vladimír Čunát wrote:
On 25/11/2021 13.00, Petr Špaček wrote:
IMHO in the context of NSEC3 the salt would make sense _only_ if it
were rotated faster than attacker was able to walk the zone. Once
attacker has list of hashes available for offline cracking the salt
does not
I like the text and how it's improving.
Note that a validating resolver MUST still validate the signature over
the NSEC3 record to ensure the iteration count was not altered since
record publication (see {{RFC5155}} section 10.3).
It might be better to clarify that this "MUST" does not
On 25/11/2021 13.00, Petr Špaček wrote:
IMHO in the context of NSEC3 the salt would make sense _only_ if it
were rotated faster than attacker was able to walk the zone. Once
attacker has list of hashes available for offline cracking the salt
does not do anything useful anymore.
I disagree;
On 26. 11. 21 9:43, Matthijs Mekking wrote:
On 25-11-2021 13:00, Petr Špaček wrote:
On 25. 11. 21 9:33, Matthijs Mekking wrote:
3.2. Recommendation for validating resolvers
I understand why the new text is here, but I think this now actually
gives too little advice for operators and
On 25-11-2021 13:00, Petr Špaček wrote:
On 25. 11. 21 9:33, Matthijs Mekking wrote:
3.2. Recommendation for validating resolvers
I understand why the new text is here, but I think this now actually
gives too little advice for operators and vendors.
I know, this is a vague comment, I
