Re: [dns-privacy] WGLC : draft-ietf-dprive-unilateral-probing

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: dns-privacy <[e-mail]> On Behalf Of Brian
> Haberman
> Sent: Sunday, March 12, 2023 11:43 AM
> To: [e-mail]
> 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