> On 6 Mar 2020, at 13:32, Eric Rescorla <[email protected]> wrote: > > > > On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson <[email protected] > <mailto:[email protected]>> wrote: > > >> On 29 Feb 2020, at 02:03, Eric Rescorla <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On 23 Jan 2020, at 13:53, Eric Rescorla <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> >>>> On 20 Jan 2020, at 22:37, Eric Rescorla <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Review comments attached: >>>> >>>> >>>> COMMENTS >>>> S 3.1. >>>> > described above, and may not have any confidentiality requirements. >>>> > However, the same is not true of a single transaction or a sequence >>>> > of transactions; that transaction is not / should not be public. A >>>> > typical example from outside the DNS world is: the web site of >>>> > Alcoholics Anonymous is public; the fact that you visit it should >>>> > not >>>> > be. >>>> >>>> Well, technically what you want to conceal is the origin of the >>>> transaction or its linkage to other transactions. The existence of the >>>> query for that A record isn't secret. >>> >>> Suggest: >>> >>> “that transaction (and specifically the origin of that transaction) is not >>> / should not be public." >>> >>> The parenthetical swallows the main sentence. The accurate thing to say is: >>> >>> In general, the existence of a single query is not sensitive -- though >>> there may be exceptions >>> for some very low use domains. However, the origin of a given query may >>> leak information >>> about specific users and the ability to link queries reveals information >>> about individual use >>> patterns. >> >> To fit with existing text suggest: >> >> However, the same is not true of a single transaction or a sequence >> of transactions; those transaction are not / should not be public. A single >> transactions reveals both the originator of the query and the query >> contents which potentially leaks sensitive information about a specific >> user. A >> typical example from outside the DNS world is: the web site of >> Alcoholics Anonymous is public; the fact that you visit it should not >> be. >> >> I find this text a bit clumsy, but OK. >> >> >> Furthermore, the ability to link queries reveals information about >> individual use patterns. >> >> The key thing is "link queries as being from the same user” > > OK - will include that. > > >> >> >> <snip> >> >>> >>> >>>> >>>> >>>> >>>> >>>> S 3.4.2. >>>> > services available. Given this, the choice of a user to configure a >>>> > single resolver (or a fixed set of resolvers) and an encrypted >>>> > transport to use in all network environments can actually serve to >>>> > identify the user as one that desires privacy and can provide an >>>> > added mechanism to track them as they move across network >>>> > environments. >>>> >>>> I don't understand this paragraph. It's not the choice of specific >>>> resolvers that leaks data, but the choice to turn on encryption, In >>>> fact, from an identification purpose, the more resolvers that support >>>> encrypted transport, the better signal this is. >>> >>> This was driven by an observation that many early adopters set up their own >>> DoT server and used that from all their devices, which could act as a way >>> to identify that user. >>> >>> 1. This seems like an edge case. >>> 2. We already have plenty of people running their own unencrypted resolvers >>> for other reasons. >> >> I can live with removing this text, but it does seem there is something to >> say about the fact configuring a single resolver for a device could >> differentiate a user…. >> >> Sure, but this has nothing to do with DoH or DoT. >> >> >> I think the text might be clearer if the bit "as one that desires privacy >> and" were removed. >> The issue isn't whether a specific user desires privacy, it is whether a >> specific user can be identified and tracked. >> >> This RFC update, is about privacy. >> This particular section is on encrypted transport. >> This paragraph is highlighting that configuring a static list of resolvers, >> even if those use encrypted transport, may expose the user to privacy risks >> due to that constant set of resolvers, as the user moves between networks. >> And this risk is inversely proportional to the number of users of the >> resolver. >> Maybe this last bit needs to be added to emphasis why this is a risk? >> >> It's about the fact that DoH/DoT don't protect against this or mitigate it, >> even if the payload is encrypted. I.e. it doesn't not have anything to do >> with DoH/DoT; it's bigger than DoH/DoT, and DoH/DoT don't fix the problem. >> >> Yes, I agree with that, but this risk is generic to DNS even if you use your >> own resolver (e.g., pihole) which we know people do. Therefore it does not >> belong in this section as a risk of DoH/DoT.. > > I think the more general case is alluded to in the forth bullet point of > section 3.4.1 without being called out specifically…. > > One option would be update the first sentence of that bullet point to say > “The recursive resolver can be a public DNS service (or a privately run DNS > resolver hosted on the public internet).” and to add the following sentence > to the end of the bullet point > > “It can be noted that the choice of a user to configure a single resolver > (even when using an encrypted transport) can actually serve to aid tracking > of that user as they move across network environments." > > Then remove the fifth paragraph from section 3.4.2? > > This seems close. > > "It can be noted that if the user selects a single infrequently used resolver > (even when using an encrypted transport) it can actually serve to aid > tracking of that user as they move across network environment" > > I think we can agree that using Google Public DNS probably doesn't have this > property.
Agreed - I might say ’selects a single resolver with a small client population (even when….’ just to make clear the infrequent usage relates to number of clients not query rate :-) > >> >> >> >> >>> >>>> >>>> >>>> S 3.5.1..1.2. >>>> > >>>> > o communicate clearly the change in default to users >>>> > >>>> > o provide configuration options to change the default >>>> > >>>> > o provide configuration options to always use the system resolver >>>> >>>> I get that you think this is neutral, but all of this is equally true >>>> about dynamic discovery via DHCP, it's just that that's the status >>>> quo, so you don't notice it. In this context, this text is tendentious. >>> >>> The first paragraph of section 3.5.1.1 talks about the variability of DNS >>> resolution privacy with network (assuming DHCP). I can add some text there >>> to better explain the status quo if you think it is needed. Suggest: >>> >>> “Typically joining a new network requires some form of user action (e.g >>> physically plugging in a cable or selecting a network in a OS dialogue) and >>> so a user is also implicitly choosing to use the DHCP-provided resolver via >>> this action too." >>> >>> The user has no idea that such a DHCP resolver even exists. And you could >>> say the same thing about the user's choice to install an application with >>> its own resolver selection logic. >>> >>> >>> I can’t think of a mobile or desktop OS that doesn’t allow users to >>> override the DHCP provided DNS settings…. but I could text about that in >>> section 5.1.1. if you really think it is needed? >>> >>> This isn't about that. AFAICT most major applications also allow you to use >>> the system resolver choices. Rather, the issue here is the repeated >>> arguments in this discussion (which you implicitly accept above) that the >>> current status quo somehow represents user choice whereas an application >>> choosing its own resolver does not. And both this text and your proposed >>> text implicitly takes a position on that. >> >> I think that is reading quite a bit into the text however, to reduce any >> implicit misinterpretation I propose trying to further align the two >> sections… >> >> 1) Replace the first paragraph in section 3.5.1.1 with the following: >> >> "Given all the above considerations, the choice of recursive resolver has >> direct privacy considerations for end users. Historically, end user devices >> have used the DHCP-provided local network recursive resolver. Because of >> this, the choice by a user to join a particular network (e.g. by physically >> plugging in a cable or selecting a network in a OS dialogue) also determines >> the default system DNS resolver selection; the two are directly coupled in >> this model. >> >> The vast majority of users do not change their default system DNS settings >> and so implicitly accept the network settings for DNS. The network resolvers >> have therefore historically been the sole destination for all of the DNS >> queries from a device. These resolvers may have strong, medium, or weak >> privacy policies depending on the network. Privacy policies for these >> servers may or may not be available and users need to be aware that privacy >> guarantees will vary with network. >> >> All major OS’s expose the system DNS settings and allow users to manually >> override them if desired.” >> >> >> 2) And replace the second paragraph of 3.5.1.1.2 with this: >> >> "Such application-specific settings introduce new control points on end user >> devices for DNS resolution settings in addition to the historically used >> system settings discussed in Section 3.5.1.1. They therefore alter the DNS >> privacy considerations for the device by introducing additional destinations >> for DNS queries. >> >> Users will only be aware that a new control point (with new defaults) exists >> if an application clearly communicates this to the user on install or >> upgrade. >> >> This reflects status quo bias. If you want to say this, then you need to >> point out that essentially no OS clearly communicates that it is selecting >> the DHCP resolver. >> >> IMHO, this is fair, and probably adds a bit of clarity; perhaps some >> wordsmithing on the start of 3.5.1.1 would benefit both this and other >> subsections of 3.5.1.1. >> Suggestion: >> >> Old: "Historically, end user devices have used the DHCP-provided local >> network recursive resolver, which may have strong, medium, or weak privacy >> policies depending on the network." >> >> New: "Historically, end user devices have used the OS-selected recursive >> resolver, whose identity is not exposed or discoverable. The OS may have >> been configured with a static set of resolvers, or may use a DHCP-provided >> local network resolver. This OS-selected resolver may have strong, medium, >> or weak privacy policies, which for DHCP provided resolvers may depend on >> the network." >> >> The gist of this is, over-riding the default has effects that the >> application cannot know, because the OS resolver choice is generally not >> known, and by extension, the privacy policies cannot be known. >> >> I don't believe this is accurate. In general there are (not that portable) >> mechanisms for determining the DNS configuration, as is done in Chromium: >> https://cs.chromium.org/chromium/src/net/dns/?sq=package:chromium&dr=CSs&g=0 >> <https://cs.chromium.org/chromium/src/net/dns/?sq=package:chromium&dr=CSs&g=0> >> > > I’m fine with Ekr’s original suggestion by replacing the last sentence in the > first paragraph with the following: > > "The choice by a user to join a particular network (e.g. by physically > plugging in a cable or selecting a network in a OS dialogue) typically > updates a number of system resources - these can include IP addresses, > availability of IPv4/IPv6, DHCP server, and DNS resolver. These individual > changes, including the change in DNS resolver, are not normally communicated > directly to the user by the OS when the network is joined. The choice of > network has historically determined the default system DNS resolver > selection; the two are directly coupled in this model. > > WFM. > > > >> >> >> >> >> >> >> >> The vast majority of users do not change default application-specific >> settings and so implicitly accept the application-specific settings for DNS. >> As with network resolvers, these resolvers may have strong, medium, or weak >> privacy policies depending on the application. Privacy policies for these >> servers may or may not be available and users need to be aware that privacy >> guarantees will vary with each application. >> >> For users to have the ability to inspect and control the >> application-specific DNS settings in a similar fashion to the OS DNS >> settings, each application must also: >> >> o expose the default settings to the user >> >> o provide configuration options to manually override the default settings >> >> o provide configuration options to always use the system resolver" >> >> This last point is wrong. The parallel here would be to use the *network >> provided* resolver, not the system resolver. I would suggest that you be >> less prescriptive about this and just say "applications will need to provide >> user-visible options to configure the resolver." I would avoid "must" (even >> in lower case) because this is a statement of fact, not a normative one. > >> >> No, system resolver is accurate. In addition to not knowing what possible >> resolver is offered by DHCP, the application can't know if DHCP (i.e. >> network provided) is even being used -- the system could be using a static >> choice of resolver, or even other non-DNS resolution services (e.g. NIS+). >> >> It turns out that there are at least three options here: >> >> - Select your own resolver >> - Select the resolver *configured into the system* (AIUI this is what Chrome >> does). >> - Use the system resolver via the conventional API calls. > > Suggest: > > "For users to have the ability to inspect and control the > application-specific DNS settings in a similar fashion to the OS DNS > settings, each application also needs to: > > o expose the default settings to the user > > o provide configuration options to manually override the default settings > so that resolution is performed via > * user specified resolvers > * the resolvers configured into the system settings > * the system resolver via conventional API calls > > If all such applications are updated to use the system resolver, as described > in the last bullet point, the device reverts to a single point of control for > all DNS queries." > > Hmm.... this seems unduly prescriptive. Perhaps. > > For users to have the ability to inspect and control the > application-specific DNS settings in a similar fashion to the OS DNS > settings, each application also needs to expose the default settings > to the users and provide a configuration interface to change them. If > this interface includes a setting to use the system resolver, then the > device can be reverted to a single point of control for all DNS > queries. > > I think this removes the status quo bias. I’d be OK with removing the sub-second bullet point but I think the other two have specific existing use cases: - ‘change them’ doesn’t explicitly allow for user specified resolvers which all OS’s do - without the option to disable the application-specific resolution a user cannot apply device level controls to their DNS queries (logging, filtering or rules directing different queries to different resolvers) in a way that can be done today. Sara. > That said, I'd like to hear from people > who implement their own resolver even for Do53. I know Chrome does > this and I believe it's quite common for SIP stacks due to performance > concerns with the system resolver. > > -Ekr > > > > Sara. > >> >> -Ekr >> >> >> Brian >> >> >>> >>> >>> The point in section 3.5..1.1.2 terms of privacy considerations is that >>> any application that uses an application specific DNS setting introduces >>> another control point on the device for the DNS resolution setting (which >>> with the current offerings is independent of the network used), and if or >>> how that is exposed is entirely up to the application. I suggest adding >>> this text at the start of the second paragraph: >>> >>> "Such application-specific settings introduce new control points on end >>> user devices for DNS resolution settings in addition to the historically >>> used system settings." >>> >>> Well, I suppose this is true, but it's also true of (for instance) allowing >>> the user to set a proxy, which we've done forever. >>> >>>> >>>> >>>> S 3.5.1.1.2. >>>> > >>>> > Application-specific changes to default destinations for users' DNS >>>> > queries might increase or decrease user privacy - it is highly >>>> > dependent on the network context and the application-specific >>>> > default. This is an area of active debate and the IETF is working >>>> > on >>>> > a number of issues related to application-specific DNS settings. >>>> >>>> This, too, could be said about the current situation. >>> >>> See above. >>> >>> And my response above.. >>> >>> -Ekr >>> >>> >>> Sara. >>> >>>> >>>> On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Thanks to Sara and Stéphane for the -04 revised I-D. >>>> >>>> After reading the -04, I think that most of the IETF Last Call comments >>>> are addressed (and consensus needs to be balanced -- even for >>>> informational document) and that the document sticks to facts. >>>> >>>> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of >>>> discussions during the first IETF Last Call, and as the authors reacted to >>>> those comments by deep changes in the text, let's have a new IETF Last >>>> Call before proceeding with IESG evaluation. >>>> >>>> Again, thank you to the reviewers and the authors >>>> >>>> Regards, >>>> >>>> -éric >>>> >>>> >>>> On 20/01/2020, 22:34, "IETF Secretariat" <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> IESG state changed: >>>> >>>> New State: Last Call Requested >>>> >>>> (The previous state was Waiting for AD Go-Ahead::AD Followup) >>>> >>>> The previous last call raised several points. The authors have worked >>>> on those points and this new informational IETF draft has substantive >>>> changes; enough to go trigger a new IETF Last Call. >>>> >>>> -éric >>>> >>>> Datatracker URL: >>>> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ >>>> <https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/> >>>> >>>> >>>> >>>> _______________________________________________ >>>> dns-privacy mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/dns-privacy >>>> <https://www.ietf.org/mailman/listinfo/dns-privacy> >>>> >>> _______________________________________________ >>> dns-privacy mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/dns-privacy >>> <https://www.ietf.org/mailman/listinfo/dns-privacy> >> >> _______________________________________________ >> dns-privacy mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/dns-privacy >> <https://www.ietf.org/mailman/listinfo/dns-privacy>
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
