> -----Original Message----- > From: dns-privacy <[email protected]> On Behalf Of Brian > Haberman > Sent: Tuesday, March 23, 2021 10:11 AM > To: [email protected] > 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... > > On 3/19/21 7:10 AM, Hollenbeck, Scott wrote: > > 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." > > > > >From the pure user perspective, do they even know that their "DNS > server" is an intermediary?
[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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
