> -----Original Message----- > From: dns-privacy <dns-privacy-boun...@ietf.org> On Behalf Of Brian > Haberman > Sent: Sunday, March 12, 2023 11:43 AM > To: dns-privacy@ietf.org > Subject: [EXTERNAL] [dns-privacy] WGLC : > draft-ietf-dprive-unilateral-probing > > All, > This starts a 2-week WGLC for > draft-ietf-dprive-unilateral-probing-05. This call is to determine if the > document is sufficiently complete to facilitate implementations and > interoperability testing. Once that determination is made, the chairs will > park > this document in the datatracker with a state of "Waiting for > Implementation" > and we will await for the requested implementations and interoperability > reports.
[SAH] The operational practices described in the draft are, I believe, complete. They are, however, based on two normative references that are incomplete, or potentially incomplete, for the purpose of recursive-to-authoritative encryption. As I noted on-list previously, RFC 7858 (DoT) explicitly notes that it "focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic" and that "It might work equally between recursive clients and authoritative servers". Section 5.1 of RFC 9250 (DoQ) explicitly notes that "For the recursive to authoritative scenario, authentication requirements are unspecified at the time of writing and are the subject of ongoing work in the DPRIVE WG". Implementations of this draft could help identify the unknowns in RFC 7858 and RFC 9250. I support the research and experimentation effort needed to address those unknowns, and I will suggest again that the draft should include text to explicitly acknowledge the limitations that are plainly described in both RFCs. The draft could note these limitations in Section 2.2 by changing the first paragraph from this: "Although this document focuses specifically on strategies used by DNS servers, it does not go into detail on the specific protocols used because those protocols, in particular DoT and DoQ, are described in other documents." To this, or something similar: "Although this document focuses specifically on strategies used by DNS servers, it does not go into detail on the specific protocols used because those protocols, in particular DoT and DoQ, are described in other documents. DoT explicitly notes that it "focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic" and that "It might work equally between recursive clients and authoritative servers". Section 5.1 of DoQ explicitly notes that "For the recursive to authoritative scenario, authentication requirements are unspecified at the time of writing and are the subject of ongoing work in the DPRIVE WG". Additional specification work might be required to ensure that DoT and DoQ work reliably in this context." I do not support the draft without text that addresses these limitations in its normative references. It would also be helpful to include text that explains the goals behind it being parked. An "Implementation Status" section as described by RFC 7942 could serve that purpose, and it could be expanded as implementations are identified. > The chairs will note that the document is currently marked as Proposed > Standard and that there has been a suggestion to move it to Experimental. If > you have an opinion on the status at this time, please include it in your > feedback to the WG mailing list. We will revisit the status of the document > before it gets advanced to our AD. [SAH] The suggestion was made to align the status of this document with the working group's charter: "Investigate potential solutions for adding confidentiality to DNS exchanges involving authoritative servers (Experimental)." This working group is not currently chartered to develop a standards track specification for "adding confidentiality to DNS exchanges involving authoritative servers". As such, I support alignment of the draft's intended status with the working group's charter (moving it to Experimental) while it's parked in the "Waiting for Implementation" state. Scott _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
