Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Vladimír Čunát <[e-mail]>]

On 22/02/2022 20.02, Geoff Huston wrote:
> I’m not sure I follow that latter comment relating to "a validating resolver returning an insecure response" - Do you mean:
>
> a) - a DNSSEC-validation capable resolver responding to a query that had the CD bit set?
>
> b) - a DNSSEC-validation capable resolver responding to a query that had no EDNS(0) extensions at all?
>
> c) - a DNSSEC-validation capable resolver responding to a query that received an NSEC record signed with an algorithm, that was not recognised by the resolver?

Oh, I'm sorry, I thought it would be perfectly clear in the context of 
this previous e-mails in this thread and the draft's paragraphs directly 
preceding the diff I posted.

Anyway, let me explain why our current code would violate the text but 
not the intent (or security properties).  It's about the "may SERVFAIL" 
case, defined as
 > Validating resolvers MAY also return SERVFAIL when processing NSEC3 
records with iterations larger than 0.

I believe that the cleanest and least bug-prone way to implement this 
sub-case is to simply ignore any NSEC3 records with iterations over the 
limit.  You do not need to check any kind of signatures or any further 
properties, as it's just trading one SERVFAIL for another SERVFAIL.  
(OK, maybe the EDE code or similar diagnostics could suffer a little, 
but I'm not convinced the complications are worth it.)  Now, this 
implementation approach would get into conflict with that sentence:
 > Note that a validating resolver MUST still validate the signature

so I was trying to suggest a simple way of patch it up to avoid 
colliding with the implementation approach that I find useful.  I don't 
really care about particular formulation, but I'd find it a bit 
unfortunate if I had to choose between not strictly following the RFC or 
complicating the implementation (unnecessarily in my view).

I hope I've stated my argument clearly now.  Thanks for bearing with me.
--Vladimir