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 <nore...@ietf.org> > Envoyé : vendredi 30 juin 2023 00:01 > À : dns...@ietf.org > Cc : dnsop@ietf.org; draft-ietf-dnsop-structured-dns- > error....@ietf.org > 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. One > obvious scenario that presents difficulties is a client expecting > EXTRA-TEXT to contain human readable contents which it displays to > an end-user, which would now (upon encountering a resolver > implementing this draft) instead display JSON blobs intended for > machine consumption to the user. This seems undesirable to me, but > the draft is silent on whether this is an accepted consequence of > the updates, simply overlooked or can be avoided in some way. > > At the very least, this situation should be discussed and > acknowledged as OK in the draft, or ideally consideration of how > to handle it - e.g. was a separate EDNS option code for > structured-error considered? > > **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. > > How is a client meant to determine if the EXTRA-TEXT field > contains invalid JSON or simply plain text? Is it envisaged that > the client performs some sort of content detection to determine > whether the field is plain-text or JSON before trying to parse it > as JSON - if so how? Or if the field cannot be parsed as JSON then > why can’t the client simply treat it as plain text? > > Again this seems to call for a discussion of why the existing EDNS > option code is being reused. Attempting to deal with either human > or machine readable data in a single field is generally a fraught > and dangerous choice in protocol design, and the presence of these > two conflicting requirements is a clear example of why. > > The use of a separate EDNS option code for human-readable vs > machine-readable extended error information would provide a clean > solution, but is not discussed. > > **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. , 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." We need to better articulate the text in Section 10. 3) (nit) the link/reference to > #server-response in the text is not working [Med] Fixed. Thanks. > > **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 sentence needs re-wording to clarify this, and I would > suggest refactoring the entire paragraph into two parts, one which > explains the issues with the actual filtering methods, and then a > second part which separately covers why the existing EDE responses > are insufficient for the use-cases this draft intends to support. > Separating this explanation into two parts avoids the confusion > the text currently introduces around whether or not RFC8914 is a > filtering method or an information method. > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
