Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-rfc7816bis-10: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The discussion about how many labels to add at each step is rather spread out amongst Sections 2, 2.3, and 3, and my preference would be to have a single more-clear specification of behavior for the Proposed Standard level of publication (but this is just a non-blocking comment and I recognize that addressing it would require somewhat invasive changes to the text). Looking over the diff from RFC 7816, I see that the discussion of empty non-terminals has been removed. Is that because the prevalence of servers that fail to handle them properly in the wild has dropped to an insignificant level? (If so, hooray!) If not, why was the text removed? We also removed the discussion of "some broken name servers [that] do not react properly to QTYPE-NS requests", which is mostly understandable since we no longer recommend that NS is used as the QTYPE for masking minimized requests. I don't know if it's worth retaining this warning in some form as it might apply to legacy implementations that retain the RFC 7816 behavior. Thanks to Donald Eastlake for the secdir review. I echo the intdir reviewer's question about where "strict mode" of QNAME minimization is defined. I also see the genart reviewer's question about whether the number of labels per iteration can remain large after the division, and I think that the maximum allowed length of a domain name helps some here, but would appreciate if someone more familiar with the actual limits ran the numbers and opined that the resulting number of labels is capped at some reasonable bound. Abstract If the note about the WG and git source is expected to be removed before publication as an RFC, it seems prudent to note that somewhere (whether in the visible prose or as a comment in the XML). Section 2.1 The QTYPE to use while minimising queries can be any possible data type (as defined in [RFC6895] Section 3.1) for which the authority always lies below the zone cut (i.e. not DS, NSEC, NSEC3, OPT, TSIG, TKEY, ANY, MAILA, MAILB, AXFR, and IXFR), as long as there is no relation between the incoming QTYPE and the selection of the QTYPE to use while minimising. [...] At risk of being overly pedantic, the procedure will still get you the right answer even if there is a relation between the incoming and selected QTYPE, so the "can be ... as long as" isn't quite correct. We insist on the lack of relationship because that gives better privacy properties, not because it is required for correct behavior, as I understand it. Section 3 (3) If CHILD is the same as QNAME, or if CHILD is one label shorter than QNAME and the original QTYPE can only be at the parent side (like QTYPE=DS), resolve the original query as normal starting from ANCESTOR's name servers. Start over from step 0 if new names need to be resolved as result of this answer, for example when the answer contains a CNAME or DNAME record. We might want to reference RFC 6672 for DNAME (since we use it later in step 6 as well). Section 6 the amount of data sent also, in part, addresses the case of a wire sniffer as well as the case of privacy invasion by the servers. Who are "the servers"? Section 7.1 It seems rather unconventional to make a normative reference to the document being obsoleted (RFC 7816). It seems like that document would be more appropriately classified as an informative reference. Section 7.2 Deferring to RFC 8499 for terminology definitions may well merit classifying it as a normative reference. NITS Thanks for putting the git repo link in the Abstract. Since I only have a proposed wording for one of these I didn't go through the effort of phrasing it in the form of a patch, but it's nice to have the option available. Section 3 (4) Otherwise, add the next relevant label or labels from QNAME to the start of CHILD. The number of labels to add is discussed in Section 2.3. It might be worth being a little more explicit that this is updating the current value of CHILD, as opposed to producing a new temporary value consisting of (next relevant label or labels)+CHILD. (E.g., "Update the value of CHILD to consist of [...]".) Section 4 have been A. Using the most used QTYPE to hide the original QTYPE therefore slightly reduces the number of outgoing queries. I'd probably say "compared to using any other QTYPE to hide the original QTYPE". Section 6 QNAME minimisation's benefits are clear in the case where you want to decrease exposure to the authoritative name server. But minimising I'd probably clarify "exposure of what?". _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
