Re: [DNSOP] nsec3-parameters opinions gathered

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

On 09. 11. 21 18:57, Viktor Dukhovni wrote
>> On 9 Nov 2021, at 4:11 am, Petr Špaček <[e-mail]> 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.

Agreed, 1 is probably what we will have to live with in spec for validators.

> 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.

+1

Petr Špaček