Re: [DNSOP] nsec3-parameters opinions gathered

[Viktor Dukhovni <[e-mail]>]

> On 5 Nov 2021, at 3:19 pm, Olafur Gudmundsson <[e-mail]> wrote:
> 
> Publishing iteration count higher than 10 is reckless as that affects the performance of recursive resolvers in particular the ones that run on small CPE equipment.
> 
> The document should strongly discourage any use of NSEC3 <full stop> 
> For the <censored> that want to keep using it the limit should be real low of what resolvers accept. 
> Any value between 0 and 10 is fine with me 

I hope to see some hint of consensus at the meeting, but would
like to mention, that a realistic *aggressive* target would 20
rather than 10.  There are >0.5M zones with 20 iterations, and
it is likely too much work for insufficient gain to get them to
reduce this to 10 or less.

If the WG consensus it to go *aggressive*, then the limit should
I suggest be 20.  Other plausible values that non-trivially reduce
impact are 40, 50 and 100.

The multiple-choice question for the recommended resolver limits
(highest accepted, not lowest rejected) is then:

	A. 20
        B. 40
	C. 50
        D. 100
	E. 150

And as for SERVFAIL, note that wildcard responses are often NSEC3
authenticated, so they'd stop working in zones over the SERVFAIL
limit.  Therefore, I think the choices here are more limited, unless
we're planning to hold off resolver implementation until many more
zones make changes post publication of the RFC.  In the short run,
the realistic upper bounds before SERVFAIL are:

	A. 150		(More stringent current de facto limit)
	B. 500		(Raytheon special)
	C. Never	(Carrot sans stick)

If some zones don't care that they're now insecure, we can report
their DoE and wildcards as insecure, and hope they'll eventually
care.

Meanwhile, their positive answers still validate, but can be freely
replaced with an insecure NODATA (zone apex) or any insecure answer
(positive, NODATA or NXDOMAIN) at any qname properly below the zone
apex.

-- 
	Viktor.