On 21/10/2021 23.20, Viktor Dukhovni wrote:
2. Resolvers could still cope with such numbers pretty confidently.
This is where I'm looking for experienced feedback from resolver
maintainers and operators.
I don't think that NSEC3 hashing could consume significant resources in
*normal* traffic. The only real risk I see is that expensive parameters
might get utilized in some DoS attack, so I'd focus on worst-case scenarios.
Salt length: that's what I'd additionally restrict, because 255 bytes
make even less sense than high iterations and it's quite expensive -
salt gets added on every iteration, so the expenses multiply each other.
Example micro-benchmark doing just the NSEC3 hashing shows that even
quite long 32B salt has little effect but 255B adds a noticeable
multiplicative factor. Therefore I'd suggest that NSEC3 records with
salt > 32B may be ignored or something similar; I don't expect they
really exist in practice and we still shave some factor from attacks.
That's all assuming we can't afford pushing the validator limits very
close to zero iterations.
iter, salt, us / hash
0, 0, 0.14
0, 32, 0.16
0, 255, 0.47
50, 0, 3.72
50, 32, 4.66
50, 255, 21
150, 0, 10.7
150, 32, 13.7
150, 255, 62
(gnutls using SHA extensions on zen1 CPU, but the conclusion was also
confirmed by Peter van Dijk on a different stack)
--Vladimir | knot-resolver.cz
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
