Subject: [dns-privacy] draft-ietf-dprive-phase2-requirements: The User Perspective and Use Cases

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 19 Mar 2021 11:10:46 +0000

Section 9.1 of draft-ietf-dprive-phase2-requirements currently contains this text:

"As recursors typically forwards queries received from the user to authoritative servers.  This creates a transitive trust between the user and the recursor, as well as the authoritative server, since information created by the user is exposed to the authoritative server.  However, the user never has a chance to identify what data was exposed to which authoritative party (via which path).

Also, Users would want to be informed about the status of the connections which were made on their behalf, which adds a fourth point

Encryption/privacy status signaling

*TODO*: Actual requirements - what do users "want"?  Start below:"

I'm not sure there's much to be added here since users currently have no ability to pick and choose services that a recursive resolver negotiates with an authoritative name server. The user can pick a recursive resolver based on the set of services it provides, and that's about it. I'd like to suggest that we replace the above text with something like the following:

"Recursive resolvers typically act as intermediaries.  They forward queries received from users to authoritative servers without any configurable and/or measurable interaction between the user and the authoritative name servers. As when making requests through other intermediaries, users do not necessarily have the ability to identify information that is disclosed by the intermediary to other service provider, i.e., an authoritative server in this case. As such,
users should simply choose a recursor that provides a set of services that best meets the user's need for information protection, along with other considerations."

Scott

---

From: Brian Haberman <[email-masked]>
Date: Tue, 23 Mar 2021 10:11:16 -0400

Hi Scott,
     Thanks for kicking this discussion off. A question (or two) inline
for us to consider...

>From the pure user perspective, do they even know that their "DNS
server" is an intermediary?

What phase 2 requirement can be derived from the above?

Regards,
Brian

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 23 Mar 2021 15:26:42 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Brian
> Haberman
> Sent: Tuesday, March 23, 2021 10:11 AM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [dns-privacy] draft-ietf-dprive-phase2-
> requirements: The User Perspective and Use Cases
> 
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content
> is safe.
> 
> Hi Scott,
>      Thanks for kicking this discussion off. A question (or two) inline for us to
> consider...
> 
> > "As recursors typically forwards queries received from the user to
> authoritative servers.  This creates a transitive trust between the user and
> the recursor, as well as the authoritative server, since information created by
> the user is exposed to the authoritative server.  However, the user never has
> a chance to identify what data was exposed to which authoritative party (via
> which path).
> >
> > Also, Users would want to be informed about the status of the
> > connections which were made on their behalf, which adds a fourth point
> >
> > I'm not sure there's much to be added here since users currently have no
> ability to pick and choose services that a recursive resolver negotiates with an
> authoritative name server. The user can pick a recursive resolver based on
> the set of services it provides, and that's about it. I'd like to suggest that we
> replace the above text with something like the following:
> >
> > "Recursive resolvers typically act as intermediaries.  They forward
> > queries received from users to authoritative servers without any
> configurable and/or measurable interaction between the user and the
> authoritative name servers. As when making requests through other
> intermediaries, users do not necessarily have the ability to identify
> information that is disclosed by the intermediary to other service provider,
> i.e., an authoritative server in this case. As such, users should simply choose a
> recursor that provides a set of services that best meets the user's need for
> information protection, along with other considerations."
> >
> 

[SAH] For most people, probably not.

> What phase 2 requirement can be derived from the above?

[SAH] There isn't one. This text appears in the Appendix, which (I believe) helps set the context for the requirements that appear in the sections that precede it without including additional requirements. If there's an intention to include requirements in Section 9, it might help to call it something other than "Appendix", to move it up higher in the document, and to think about where normative language is needed. My preference is to leave it where it is, use it to provide background information, and not include normative language.

Scott

---

From: Brian Haberman <[email-masked]>
Date: Wed, 24 Mar 2021 07:19:59 -0400

Hi Scott,

> [SAH] There isn't one. This text appears in the Appendix, which (I believe) helps set the context for the requirements that appear in the sections that precede it without including additional requi…

Sorry, I didn't word my question clearly enough. I agree that there
shouldn't be requirements in the appendix. It does serve the purpose of
providing context, but does not appear to have a direct link to any
requirements that have been documented. So, my question is does this
context lead to any specific requirement that should be captured in this
document?

Regards,
Brian

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 24 Mar 2021 11:58:58 +0000

> Sent: Wednesday, March 24, 2021 7:20 AM
> To: [email-masked]
> > [SAH] There isn't one. This text appears in the Appendix, which (I believe)
> helps set the context for the requirements that appear in the sections that
> precede it without including additional requirements. If there's an intention
> to include requirements in Section 9, it might help to call it something other
> than "Appendix", to move it up higher in the document, and to think about
> where normative language is needed. My preference is to leave it where it
> is, use it to provide background information, and not include normative
> language.
>
> Sorry, I didn't word my question clearly enough. I agree that there shouldn't
> be requirements in the appendix. It does serve the purpose of providing
> context, but does not appear to have a direct link to any requirements that
> have been documented. So, my question is does this context lead to any
> specific requirement that should be captured in this document?

[SAH] I don't think it does, and that's just as important to recognize as the other perspectives that appear in the appendix that might lead to a specific requirement. Right now, the draft leaves the question about requirements derived from the user's perspective open. I'm suggesting that we modify that text and note that the user's perspective does not introduce requirements.

Scott