[DNSOP] I-D Action: draft-ietf-dnsop-extended-error-09.txt

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

The following comments are only loosely related to multiple threads
here, so let me post them in a single bunch.

On 9/11/19 8:05 AM, Viktor Dukhovni wrote:
> Section 3.2 (code 2), may warrant more guidance on when this is
> appropriate.  AFAIK, there is nothing wrong with all DNSKEY algorithms
> being unsupported, provided the same holds for the DS RRset.  So,
> while I see a use-case for code 3 (all DS unsupported, perhaps to
> signal why the AD bit is not set, despite the non-empty DS RRset),
> I don't understand when one would use code 2.

I do fail to understand the split codes 1 and 2 for all DS/DNSKEY
algorithms being unsupported, and it actually makes me wonder how to
exactly write the resolver code that would set this pair.  For
validation I need at least one usable DS RR, i.e. one where *both* the
DS and DNSKEY algorithms are supported.  I believe that's the exact
condition to be able to extend the trust chain. (and that's how I
implemented it for Knot Resolver)  It may theoretically even happen that
there is a supported DS algorithm and a supported DNSKEY algorithm but
never paired together in the DS RRset - IIRC it's not perfectly correct
to generate such an RRset but that's probably not something a validator
should care for.


On 9/11/19 8:05 AM, Viktor Dukhovni wrote:
> Section 3.8 [...]
>
>    So just *an* expired signature is not really a problem provided
>    another signature for the same RRset is not expired.  So I think
>    the text could more clearly read "but *all* signatures for an
>    RRset in the validation chain expired", or some such.

Nitpick: *if* we were diving into such details... each RRSIG might fail
for a different reason, for example.  That's the general problem with
providing reasons for validation failures: validation is defined in the
sense that you (may) succeed when at least one of various ways
succeeds.  A failure could typically be fixed by multiple different ways
(EDE codes).  Still, I'd hope that in most real-life cases the
implementations can "correctly" guess what's wrong.


On 9/13/19 10:01 PM, Tony Finch wrote:
> 3.5.  Extended DNS Error Code 4 - Forged Answer
> 3.16.  Extended DNS Error Code 15 - Blocked
> 3.17.  Extended DNS Error Code 16 - Censored
> 3.19.  Extended DNS Error Code 18 - Filtered
>
> I don't understand the shades of meaning that these are supposed to
> distinguish.
>
> wrt "filtered", the description implies vaguely RPZ flavoured filtering,
> but it mentions a REFUSED RCODE which isn't what a sensible implementation
> would use for that purpose, so I am more confused.

With the switch to codes not specific to RCODE, I think some more
code-merging would be nice, in particular 3+19: stale (NXDOMAIN)
answer.  Perhaps also drop "4 forged" in favor of the other options?
(blocked, censored, if I understand the definitions)  Or is "forged"
meant for cases like the special top-level invalid. zone?


I think the current -09 "Security considerations" section is a bit
misleading.  It talks about the extended error being unauthenticated in
case of validation failure, but the current SERVFAIL is the very same
and that part is the more important bit (noticed by Paul Hoffman, too). 
With extended errors we only get more information of the same
authenticity.  In general, clients that don't want to validate
themselves can also choose a middle ground where they trust the resolver
and secure their link to it (typically by DoT or DoH).

Also, *if* the EDE codes will only be used for [diagnostics], I don't
really understand why have any "Security considerations" at all. 
Perhaps I'm just confused about the overall intention.
[diagnostics]
https://mailarchive.ietf.org/arch/msg/dnsop/rbkGvMH-vG-P5GHUx06-LRWYRgM


--Vladimir