Re: [DNSOP] nsec3-parameters opinions gathered

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

On 08. 11. 21 14:41, Wes Hardaker wrote:
> Petr Špaček <[e-mail]> writes:
> 
> Thanks for the detail notes Petr, very helpful.
> 
>>  From my point of view the RFC does not need to stick to the value
>> currently implemented in resolvers.
> 
> Good point, and maybe the right phrasing I should have used should have
> been "what value would implementations refuse to switch to"?

Well, the answer is the same:
For validators it's a moving target. A high value which was "necessary" 
yesterday might not be needed today because a large hoster moved on.


> In part, I worry that code authors would object to having just changed
> something and refused to change again.  It seems like reports are
> overcoming that problem though  :-)
> 
> [I'm not sure we're at zero yet...]

Sure, but that's not the point. The value is ever-changing.

As I see it, we can either:
a) Specify _a_ value valid for November 2021 and produce a RFC with 
values not reliable beyond November 2021.
b) Specify _the_ ultimate target which guarantees interoperability in 
future, and make it really clear in the text.

I think the second option is much better, so let me try this approach. 
I'm proposing text along those lines:


Addition for section
> 3.1.  Best-practice for zone publishe
----
Please note that any number of iterations larger than 0 carries risk of 
interoperability problems. Any zone using higher iterations counts is 
willingly signing up for problems.
The reason for this is that DNSSEC responders and validators have to 
limit resource usage caused by excessive iteration values, and even very 
small numbers of iterations impose significant overhead, which motivates 
software vendors to drive the limit down to 0.
-----

If we really wanted we could add an appendix with an illustrative table 
(with disclamer about being just ilustrative for one software version, 
point in time, hardware etc. etc.):

| Iterations | QPS [% of 0 iterations QPS] |
|------------|-----------------------------|
| 0          | 100 %                       |
| 10         | 89 %                        |
| 20         | 82 %                        |
| 50         | 64 %                        |
| 100        | 47 %                        |
| 150        | 38 %                        |

If we wanted a simpler example we could say something like "at the time 
of this writing, mere 10 iterations caused over 10 % QPS drop on two 
popular authoritative server implementations".
(As a sanity check I just tested Knot DNS and the impact there is very 
similar to what we see in the table about for BIND.)

Honestly I don't think it's necessary.


As for
> 3.2.  Recommendation for validating resolvers

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?

-- 
Petr Špaček