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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
