Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Puneet Sood <[e-mail]>]

Wes,

I read and diffed version 12 but did not find text addressing some of
my comments.

On Fri, Sep 27, 2019 at 7:41 PM Wes Hardaker <[e-mail]> wrote:
>
> Puneet Sood <puneets=[e-mail]> writes:
>
> Hi Puneet,
>
> Thanks for the comments.  Responses are inline below in my tracking
> notes below.
>
> 14.5 TODO Puneet Sood
> ~~~~~~~~~~~~~~~~~~~~~
>
>   I got around to review the draft only recently and have made an
>   attempt to avoid points of discussion that have been resolved since
>   IETF Prague. Apologies in advance for any duplicates.
>
>
> * 14.5.0.1 DONE 1. Introduction and background
>
>   Para 2: "A good example of issues that would benefit ..."  Comment:
>   The paragraph leads up to the conclusion that the EDE codes will be
>   helpful to a client to decide between retry and stopping.  Since the
>   consensus is that the EDEs are purely diagnostic, it would be good to
>   reiterate that at the end of this paragraph.
>
>   + Response from Viktor: For the record, while that was
>   "diagnostic" was my take on the purpose of these codes, reading other
>   responses, I am not sure that's yet the consensus view...  I could
>   also live with these being actionable, provided the text is then more
>   clear on how to do that correctly
>
>   If the actions based on these codes are arbitrary choices for each
>   implementation, with not even a clear correspondence with associated
>   RCODEs, that feels like too much rope to me...
>
>   Eric Orth's comment from Sept 17 is also relevant here (no one has
>   responded to it yet). Quoting the last bullet from his response here
>   for reference:
>   [https://mailarchive.ietf.org/arch/msg/dnsop/GTg8wa7lQ-VoBFcp_P5tT4VuQhE]
>   *Something like "applications MUST NOT act on EDE" or "applications
>   MUST NOT change rcode processing" does not seem reasonable to me.  Way
>   too unclear what "diagnostic" processing is reasonable and allowed or
>   not.  And potentially limits applications from doing processing based
>   on very reasonable or obvious interpretations of the received
>   rcode/EDE combinations."
>
>   + Response: Paul H. gave us language to put in both the abstract and
>     introduction to address this.  Let me know if you think it doesn't
>     address this issue.
LGTM

>
>
> * 14.5.0.2 TODO 2. Extended Error EDNS0 option format / forwarding /etc/
>
>   Final para: "The Extended DNS Error (EDE) option can be included in
>   any response (SERVFAIL, NXDOMAIN, REFUSED, and even NOERROR, etc) to a
>   query that includes OPT Pseudo-RR [RFC6891]. ..."
>
>   Comment: Given the level of discussion around behavior when
>   sending/receiving the EDE option, there should be some more text
>   giving guidance on behavior.
>
>   a. For recursive resolvers, it may be worth pointing that it is not
>   expected to copy/forward EDE values received from authoritative
>   nameservers to their clients.  b. What is the expectation on caching
>   for the EDE code generated by a recursive resolver in response to a
>   query? My expectation is that it will be cached (if the answer itself
>   is cached) so the next response has the same EDE code.

> c. Truncation:
>   In case a response including the EDE option with EXTRA-TEXT filled in
>   exceeds the effective UDP payload size, what is the desired behavior
>   for the EDE option? Should the EXTRA-TEXT field be left empty in favor
>   of filling in other RR types? Should the response be marked truncated
>   to require a re-query over TCP?

Independent of the decision on EDE forwarding and caching, the I-D
needs to have some guidance for it. The EXTRA-TEXT field may be
obtained from configuration and it is possible that the resulting DNS
message will exceed UDP message size limit in the request.

>
>   This is unlikely for failures but could happen when DNSSEC validation
>   could not be performed due to unsupported digest type.
>
>   + Response: good questions, and I think the WG needs to think about
>     whether to add that much more data.
>
>
> * 14.5.0.3 DONE 3.14 Extended DNS Error Code 13 - Cached Error
>
>   The resolver has cached SERVFAIL for this query.
>
>   Comment: To match the text the name should be "Cached SERVFAIL".
>
>
> * 14.5.0.4 NOCHANGE 5. Security Considerations
>
>   Para 2: "This information is unauthenticated information, and an
>      attacker (e.g a MITM or malicious recursive server) could insert an
>      extended error response into already untrusted data ..."  Comment:
>      Agree with some other comments that this is not relevant since no
>      action is expected to be taken based on EDEs.  Comment: There are
>      ideas in the thread to have links to info in the EXTRA-TEXT and
>      possibly display it to users. I guess the usual warnings to not
>      click on potentially unsafe links apply.
>
>   + Yeah, it really would be remiss to leave out that point.  There may
>     be nothing we can do, but the whole point of a security
>     consideration is to properly disclose any known threats/issues.
I do not see text mentioning this.

Thanks,
Puneet

>
>   Thanks, Puneet
>
>
>
>
> --
> Wes Hardaker
> USC/ISI