Hi Med, Thanks for the responses, further comments in-line.
On Fri, Jun 30, 2023 at 9:24 PM <[email protected]> wrote: > > Hi Matt, > > Thank you for the review. > > Please see inline. I let my co-author further comment as appropriate. > > Cheers, > Med > > > -----Message d'origine----- > > De : Matt Brown via Datatracker <[email protected]> > > Envoyé : vendredi 30 juin 2023 00:01 > > À : [email protected] > > Cc : [email protected]; draft-ietf-dnsop-structured-dns- > > [email protected] > > Objet : Dnsdir early review of draft-ietf-dnsop-structured-dns- > > error-03 > > > > Reviewer: Matt Brown > > Review result: Almost Ready > > > > I believe this draft has ambiguities that will present issues for > > implementing clients that require further discussion and > > clarification before proceeding. > > > > **Issue 1** > > RFC8914 is clear (section 2) regarding EXTRA-TEXT that “This > > information is intended for human consumption (not automated > > parsing).“. > > > > [Med] Sure. That is already called out in the spec: > > Abstract: > This document updates RFC 8914 by signaling client support for > structuring the EXTRA-TEXT field of the Extended DNS Error to provide > details on the DNS filtering. Such details can be parsed by the > client and displayed, logged, or used for other purposes. > > Introduction: > > This document describes a format for computer-parsable data in the > EXTRA-TEXT field of [RFC8914]. It updates Section 2 of [RFC8914] > which says the information in EXTRA-TEXT field is intended for human > consumption (not automated parsing). > > > Section 4 of this draft implicitly updates that requirement by > > stating that I-JSON can be sent in the field, but focuses on the > > technical aspects of the JSON structure, not on the implications > > of reversing that statement. > > > > Changing a field stated as for human consumption to a field > > intended to be machine-readable is a major change and the > > implications of this change should be discussed in the draft, > > including an explicit statement updating the intent of the EXTRA- > > TEXT field. > > > > In particular I would expect to see discussion and consideration > > of how backwards compatibility with RFC8914 compliant, but > > structured-dns-error ignorant clients would be achieved. > > [Med] Clients that are capable to consume the json format will behave as > follows: > > It SHOULD use an OPTION-LENGTH of 2, > the INFO-CODE field set to "0" (Other Error), and an empty EXTRA-TEXT > field. This signal indicates that the client desires that the server > responds in accordance with the present specification. > > The server will take that into account to elicit which format to use. Will > double check if we need to better clarify this in the text. For now, I > identified this change > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/35/files. OK! My apologies. I managed to completely overlook and miss this discrimination mechanism in my multiple readings of the draft, even when specifically trying to work out how the concerns I originally raised here would be avoided. It seems obvious to me now that you've pointed it out, but it definitely wasn't obvious to me in any of my earlier readings. I would suggest a few extra pointers to this mechanism elsewhere in the draft to help avoid my struggle in future, e.g.: * The first sentence of section 4 could change from "DNS servers that are compliant with this specification ..." to "DNS servers that are compliant with this specification AND have received an indication that the client also supports this specification as per s5.1 send I-JSON..." * In section 5.2, add some statement to cover the normal cases (e.g. "When responding to a query that did not indicate SDE support (per s5.1) the server MUST NOT return I-JSON in EXTRA-TEXT", "When responding to a query that did indicate SDE support (per s5.1) ... [existing content]". Two further clarifying questions on the mechanism itself: 1) The signaling mechanism (EDE OPT RR with OPTION-LENGTH=2, INFO-CODE=0) is the same as the default/null EDE OPT RR, yes? Is there a risk that EDE but not SDE supporting clients are already sending this default/NULL OPT RR in their queries as part of their existing EDE support? Would it make sense to require a more explicit signal? 2) Why is the client recommendation to trigger SDE behaviour on the server only a SHOULD, not a MUST? Is this just to reflect that SDE is optional in general, or are there circumstances envisaged where the client would received an SDE response even without using the mechanism specified in s5.1 ? Perhaps wording this along the lines of "A client wishing to receive structured DNS error information MUST signal its support of this specification to the server by ... " would make the intent here clearer? > > **Issue 2** > > The above ambiguity also appears to lead into conflicting > > instructions for clients in section 5.3 - specifically the first > > and third bullet points are conflicting - clients SHOULD handle > > either plaintext or JSON in EXTRA-TEXT (point 3), but MUST discard > > invalid JSON (point 1). > > > [Med] This is now reworded as follows: > > * Servers which don't support this specification might use plain > text in the EXTRA-TEXT field so that requestors SHOULD properly > handle both plaintext and JSON text in the EXTRA-TEXT field. The > requestor verifies that the field contains valid JSON. If not, > the requestor MUST consider the server does not support this > specification and stop processing rest of the actions defined in > this section. > > Hope this is better. Much improved, as a (nit), perhaps also add ", but may instead choose to treat EXTRA-TEXT as per RFC8914" for full clarity on the intended fallback path. > > > **Issue 3** > > Section 6 appears to alter DNS processing behaviour for RPZ > > servers (to avoid the use of NXDOMAIN, RA=0 in favour of the logic > > in section 5.2), there are 3 points here: > > > > 1) (issue) “can” is not a BCP 14 term > > [Med] We are not using any normative on purpose because that section is > informative. Please note that we moved that text to an appendix as per a > comment from another dns-dir review. It is not clear to me this section is only intended to be informative - perhaps stating that explicitly: "This section provides non-normative guidance for operation with an RPZ server..." would help? > > , making it unclear the > > strength of this instruction for compatible servers - I recommend > > using an explicit MAY, SHOULD or MUST term here instead of the > > ambiguous can. 2) (issue) regardless of the term used, the > > implication that the presence of an EDE option can indeed alter > > DNS processing behaviour on the server is in conflict with the > > MUST NOT directive in section 6 of RFC8194, which section 10 of > > this draft says still apply to this document. If this section 6 > > does indeed intend to override the MUST NOT security > > considerations of section 6 in RFC8194 and allow a situation where > > EDE can alter DNS processing behaviour for RPZ servers that should > > be explicitly stated (both in this section) and also in the later > > security considerations section. > > [Med] Good point. That MUST NOT was motivated because "EDE information is > unauthenticated information". > This spec requires: "The response MUST be received over an encrypted DNS > channel." If the encrypted DNS channel is indeed so central to the specification perhaps its requirement should also be mentioned in s5.1 as a requirement on the client when generating the request? > > We need to better articulate the text in Section 10. Yes, I think if the spec is intending to make the MUST NOT requirement from RFC8194 obsolete, then having that explicitly discussed and stated in the security considerations would be ideal. > > **Nit 1** > > Section 3 contains an incorrect assertion that EDE (RFC8914) is a > > DNS filtering methods stating that: “DNS responses can be filtered > > by sending a bogus (also called "forged") A or AAAA response, > > NXDOMAIN error or empty answer, or an Extended DNS Error code > > defined in [RFC8914].” - EDE is being presented as a third > > alternative for filtering. It is not. RFC8914 clearly states that > > EDE MUST NOT alter DNS processing, so an EDE cannot be used to > > filter a DNS response - EDE can only add explanatory information > > about filtering that is occuring due to another method. > > [Med] The text does not say that EDE is used for filtering, but to inform > clients that filtering happened. > An attempt to tweak the text can be seen at: > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/38/files. This reads much clearer to me now thanks. Cheers -- Matt Brown _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
