Hi Matt, Di, Thank you for the follow-up.
We released a new version that addresses both your reviews. FWIW, a diff to track the changes can be seen at: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-structured-dns-error-03&url2=draft-ietf-dnsop-structured-dns-error-04&difftype=--html Cheers, Med > -----Message d'origine----- > De : DNSOP <dnsop-boun...@ietf.org> De la part de Matt Brown > Envoyé : lundi 3 juillet 2023 10:40 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc : dns...@ietf.org; dnsop@ietf.org; draft-ietf-dnsop-structured- > dns-error....@ietf.org > Objet : Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop- > structured-dns-error-03 > > Hi Med, > > Thanks for the responses, further comments in-line. > > On Fri, Jun 30, 2023 at 9:24 PM <mohamed.boucad...@orange.com> > 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 <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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Fietf-wg-dnsop%2Fdraft-ietf-dnsop-structured-dns- > error%2Fpull%2F35%2Ffiles&data=05%7C01%7Cmohamed.boucadair%40orang > e.com%7Cf866518611f84bac03ee08db7ba13ac2%7C90c7a20af34b40bfbc48b92 > 53b6f5d20%7C0%7C0%7C638239704623560543%7CUnknown%7CTWFpbGZsb3d8eyJ > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > 3000%7C%7C%7C&sdata=d83rOc775XtiQyh9%2FAuhj6EhSxQ7OKKSZfT9jdZ3eb8% > 3D&reserved=0. > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Fietf-wg-dnsop%2Fdraft-ietf-dnsop-structured-dns- > error%2Fpull%2F38%2Ffiles&data=05%7C01%7Cmohamed.boucadair%40orang > e.com%7Cf866518611f84bac03ee08db7ba13ac2%7C90c7a20af34b40bfbc48b92 > 53b6f5d20%7C0%7C0%7C638239704623560543%7CUnknown%7CTWFpbGZsb3d8eyJ > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > 3000%7C%7C%7C&sdata=TkVxJQZwg5V9OkIk%2F7gcLJF4V7BQlCt8dqyLqJGD5VU% > 3D&reserved=0. > > > This reads much clearer to me now thanks. > > Cheers > > -- > Matt Brown > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.ietf.org%2Fmailman%2Flistinfo%2Fdnsop&data=05%7C01%7Cmohamed.b > oucadair%40orange.com%7Cf866518611f84bac03ee08db7ba13ac2%7C90c7a20 > af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638239704623560543%7CUnknown%7 > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL > CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=f3w9wuzAhzw0Vw8grpDxRxk8SxNk2y > y6Mh2RgKVH%2Bxc%3D&reserved=0 ____________________________________________________________________________________________________________ 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
