> On 9 Nov 2021, at 4:11 am, Petr Špaček <pspa...@isc.org> wrote:
>
> I don't see need to specify _a_ value here. I think better approach is
> acknowledge current state of things. What about something like this?
>
> ---
> As for November 2021, the limit of 150 iterations for treating answer as
> insecure is interoperable without significant problems, but at the same time
> it makes DoS attacks based on exhausting CPU resources three times cheaper
> when compared to 0 iterations.
>
> For this reason software vendors are expected to evaluate NSEC3 iteration
> counts seen in wild and lower their limits over time.
> ---
>
> What do you think about this approach?
I have no objections to setting the limits to essentially zero, but would
suggest:
- Authoritative servers employing NSEC3 SHOULD set the (additional)
iteration count to 0. Higher values may run into interoperability
problems with validating resolvers and secondary servers.
- Validating resolvers MAY over time reduce the maximum NSEC3
(additional) iteration count they support to as low as 1.
NSEC3 iteration counts of 0 and 1 MUST continue to be supported.
The reason I'd prefer that validators allow 1 as well as zero, is that:
* We're then probably looking at just ~1% performance impact
(extrapolated from the posted perf numbers)
* It is I think not obvious to naive operators that 0 iterations really
means 0 *additional* iterations, and the initial hashing step is still
performed. Thus 1 is a fairly popular setting, and I'm inclined to
require that it be tolerated in validators, even if we're telling
auth zone operators to use 0.
All that said, after the RFC is done, we'll need to do another round
of outreach to TLD zone aand customer domain hosting operators as well
as independent self-hosting auth zone operators, this time to ask for
a reduction to 0 (as opposed to 100 or less). I hope that won't be
principally (or alone) up to me.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
