Subject: Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>

From: Sara Dickinson <[email-masked]>
Date: Mon, 2 Mar 2020 15:16:25 +0000

> On 29 Feb 2020, at 02:03, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 23 Jan 2020, at 13:53, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> 
>>> 
>>> On 20 Jan 2020, at 22:37, Eric Rescorla <[email-masked] <mailto:[email-masked]>> 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?

> 
>  
> 
> 
>> 
>>> 
>>> 
>>> 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.

> 
> 
> 
> 
>  
> 
> 
> 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."

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-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
>>> 
>> _______________________________________________
>> dns-privacy mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 3 Mar 2020 12:34:28 +0100 (CET)

>     Il 02/03/2020 16:16 Sara Dickinson <[email-masked]> ha scritto:
> 
>     Suggest: 
> 
I don't want to nitpick, but I'd point out that from the policy/privacy viewpoint what is important is which resolver is used, not (as long as it does not add any specific new privacy risk) the interface used to contact it - so the second and third "*" bullets are functionally equivalent and it would be fine if an application provided only either one of the two.

In theory, one could say that the two interfaces are not completely privacy-equivalent, since the use of the system API introduces one more party that gets access to data, i.e. the operating system - so one could argue that applications should bypass the OS to prevent it from spying over the user's DNS traffic, exactly like they do with the network. If this is what we want to argue, then we should remove the last "*" bullet. However, exactly as the network, the OS might want to exert some general policy over the user's DNS traffic, such as monitoring infections or filtering specific destinations, so I don't know if such a recommendation would be beneficial in the end.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 5 Mar 2020 13:13:48 +0000

> On 3 Mar 2020, at 11:34, Vittorio Bertola <[email-masked]> wrote:
> 
> 

You are broadly correct,  but there are some small differences in that for the second bullet point not all applications may offer the preferred transport (e.g. most browsers don’t support DoT but my preferred resolver might only support DoT) or config options e.g. to omit the User-agent HTTP header. It will also mean X different applications making X different connections to the resolver (which could reveal the set of applications the user has installed). Whereas if everything goes through the system resolver the device appears to the resolver as a single source of queries using a set of connections managed only from the system resolver. 

> In theory, one could say that the two interfaces are not completely privacy-equivalent, since the use of the system API introduces one more party that gets access to data, i.e. the operating system…

This is an interesting point! Note that a user may want to use the system resolver as a point to monitor their own traffic. For example, having multiple sources of DNS queries doesn’t necessarily provide the same ability to troubleshoot issues as a single component does, or (more importantly) to inspect the encrypted traffic leaving the machine. Firefox nicely allows users to export session keys so the traffic can be decrypted locally (and also provides an interface to look at the DNS results), but if an application doesn’t offer this then the user may have no ability to easily see their own DNS traffic. I’ve thought in the past of proposing this as an additional option for the applications (and in future on any OS that implements an encrypted transport) but didn’t follow up.

Sara.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 Mar 2020 05:32:17 -0800

On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson <[email-masked]> wrote:

> On Fri, Feb 28, 2020 at 4:50 PM Brian Dickson <
> [email-masked]> wrote:
>
>>
>>
>> On Fri, Feb 28, 2020 at 3:15 PM Eric Rescorla <[email-masked]> wrote:
>>
>>>
>>>
>>> On Wed, Feb 26, 2020 at 6:19 AM Sara Dickinson <[email-masked]> wrote:
>>>
>>>>
>>>>
>>>> On 23 Jan 2020, at 13:53, Eric Rescorla <[email-masked]> wrote:
>>>>
>>>> On Thu, Jan 23, 2020 at 5:08 AM Sara Dickinson <[email-masked]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On 20 Jan 2020, at 22:37, Eric Rescorla <[email-masked]> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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….
>>>>
>>>
>> The issue isn't whether a specific user desires privacy, it is whether a
>> specific user can be identified and tracked.
>>
>> 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.
>> 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."
>

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.

>>>>> 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…
>>>>
>>>> "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.
>>>>
>>>> "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
>
>
> "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:
>>>>
>>> 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+).
>>
>
> "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  provide configuration options to manually override the default
> settings so that resolution is performed via
> 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. 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.
>>>>> >
>>>>> On Mon, Jan 20, 2020 at 1:47 PM Eric Vyncke (evyncke) <
>>>>> [email-masked]> wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> On 20/01/2020, 22:34, "IETF Secretariat" <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>>     IESG state changed:
>>>>>>
>>>>>>     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/
>>>>>>
>>>>>>
>>>>>>
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>>>>
>>>>>
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>>
>>>>
>>>>
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>>
>

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 9 Mar 2020 10:55:33 +0000

> On 6 Mar 2020, at 13:32, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Mon, Mar 2, 2020 at 7:16 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 29 Feb 2020, at 02:03, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
> "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 :-)

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Mar 2020 08:01:09 -0700

On Mon, Mar 9, 2020 at 3:55 AM Sara Dickinson <[email-masked]> wrote:

>>>>> 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….
>>>>>
>>>>
> 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.
>>>>>> >
>>>>> 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
>>>>> 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.
>>>>>
>>>> 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.
>>>>
>>>
>>> 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."
>>>
>> 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:
>>
>>>>> settings
>>>> 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
>>> 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+).
>>>
>>
> - 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.
>

But this is what I mean by "status quo bias". And in this case, I suspect
it's not even correct status quo bias because plenty of applications have
been doing their own name resolution for some time (and of course malware
will not have settings for this).

As I said before, we should hear from people who implement their own
resolver....

-Ekr

Sara.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 9 Mar 2020 12:18:23 -0700

On Mon, Mar 9, 2020 at 8:01 AM Eric Rescorla <[email-masked]> wrote:

>>>> The issue isn't whether a specific user desires privacy, it is whether
>>>> a specific user can be identified and tracked.
>>>>
>>> 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."
>>>
>>>>>>> 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
>>> I’m fine with Ekr’s original suggestion by replacing the last sentence
>>> in the first paragraph with the following:
>>>
>> - 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.
>>
>

I think this argument suffers from lack of supporting examples, as well as
from ambiguous terminology.

Two specific terms I see as problematic: "applications"; and "name
resolution".

The examples that should be included to reduce the ambiguity would be
actual applications, including (a) whether those require administrative
privileges to install, (b) whether those are end-user applications vs
system services (such as mail transport agents), and (c) whether/how they
make changes to resolver choice.

The term "name resolution" could be anything from making calls to installed
libraries such as "ldns", which expose additional APIs but which generally
inherit OS resolution, to the "getdns" bindings, to implementing full stub
resolver functionality. It's not enough to say some do one thing, some do
another, evaluating the assertion being made means having those details for
each application that is being offered as an example.

I'm aware of SMTP services that necessarily do their own resolution, in
order to handle a variety of things (such as MX records, SPF, DMARC, DKIM,
and even TLSA), but which largely are system-level services who are
generally configured by administrators, and generally conform to the
existing environment as far as resolver choice is concerned.

I'm not aware of end-user applications doing any kind of DNS, and I'm
reasonably confident in saying that a number of platforms, such as Apple
iOS, do not support applications that do so.

The existence of a handful of services that do DNS resolution, does not
negate the central argument, that the expectation is that the OS-configured
resolver being used for DNS is the de facto status quo for end-user systems
and infrastructure systems.

I also don't understand what the problem of status quo bias actually is,
could you explain the problem?

Brian

>>>>>>>> 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.
>>>>>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Mar 2020 13:13:41 -0700

On Mon, Mar 9, 2020 at 12:18 PM Brian Dickson <[email-masked]>
wrote:

>>>>> 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.
>>>>>
>>>>
>>>> I think the more general case is alluded to in the forth bullet point
>>>> of section 3.4.1 without being called out specifically….
>>>>
>>>>>>> "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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>> 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."
>>>>>
>>>>> 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
>>> I’d be OK with removing the sub-second bullet point but I think the
>>> other two have specific existing use cases:
>>>
> The term "name resolution" could be anything from making calls to
> installed libraries such as "ldns", which expose additional APIs but which
> generally inherit OS resolution, to the "getdns" bindings, to implementing
> full stub resolver functionality. It's not enough to say some do one thing,
> some do another, evaluating the assertion being made means having those
> details for each application that is being offered as an example.
>

As I said, Chrome does its own name resolution and has for quite some time,
using the resolvers configured into the system and then sending its own DNS
packets. This used to be common practice in SIP softphones, but I haven't
worked on one in quite some time.  I'm not sure on what basis you claim iOS
doesn't support this, as that's not my understanding. Can you provide a
citation here?

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Mon, 9 Mar 2020 14:14:45 -0700

On Mon, Mar 9, 2020 at 1:14 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Mon, Mar 9, 2020 at 12:18 PM Brian Dickson <
>>>>>>>>> “that transaction (and specifically the origin of that
>>>>>>>>> transaction) is not / should not be public."
>>>>>>>>>
>>>>>>>>
>>>>>> The issue isn't whether a specific user desires privacy, it is
>>>>>> whether a specific user can be identified and tracked.
>>>>>>
>>>>> 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 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
>>>>>>>> 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…
>>>>>>>>
>>>>>>> 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
>>>>> "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
>>>>>>> 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.
>>>>>>>>
>>> But this is what I mean by "status quo bias". And in this case, I
>>> suspect it's not even correct status quo bias because plenty of
>>> applications have been doing their own name resolution for some time (and
>>> of course malware will not have settings for this).
>>>
>>
>> I think this argument suffers from lack of supporting examples, as well
>> as from ambiguous terminology.
>>
> As I said, Chrome does its own name resolution and has for quite some
> time, using the resolvers configured into the system and then sending its
> own DNS packets. This used to be common practice in SIP softphones, but I
> haven't worked on one in quite some time.  I'm not sure on what basis you
> claim iOS doesn't support this, as that's not my understanding. Can you
> provide a citation here?
>

Sure.

From
https://developer.apple.com/documentation/networkextension/dns_proxy_provider

DNS proxy providers are only supported on supervised iOS devices.

(And the latter is described here:
https://support.apple.com/guide/apple-configurator-2/supervised-devices-apd9e4f64088/mac
 )

So basically, the ability to use third party DNS is limited to managed
devices, corporate or education.
The only other exception is the one done via VPN services, which is a
different set of frameworks, IIUC.
(That's why 1.1.1.1 is a VPN app rather than just a resolver, I believe.)

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
>>>>>>>>> "Such application-specific settings introduce new control points
>>>>>>>>> on end user devices for DNS resolution settings in addition to the
>>>>>>>>>>     The previous last call raised several points. The authors
>>>>>>>>>> have worked on those points and this new informational IETF draft has

---

From: Jim Reid <[email-masked]>
Date: Mon, 9 Mar 2020 21:18:59 +0000

Could the people on this thread *please* trim their postings? It's hard to track the discussion when every email contains a jumbled set of a gazillion postings. Thanks.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 9 Mar 2020 14:22:59 -0700

Hi, Jim,

I was planning on replying to you with a just-for-you trimmed version, but
your email server refuses email I send (I use gmail... I know...), but
yeah, I will in future trim the replies.
Brian

On Mon, Mar 9, 2020 at 2:19 PM Jim Reid <[email-masked]> wrote:

> Could the people on this thread *please* trim their postings? It's hard to
> track the discussion when every email contains a jumbled set of a gazillion
> postings. Thanks.
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Mar 2020 14:57:55 -0700

> (That's why 1.1.1.1 is a VPN app rather than just a resolver, I believe.)

Ah. I think we are talking about different things:

- Yes, it seems like iOS does not officially support an app which provides
DNS services for other apps (though apparently there is an unofficial way
to do it via the VPN hooks)
- Individual apps, however, are able to do their own DNS resolution via the
obvious mechanism of sending their own UDP packets to port 53.

-Ekr

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 Mar 2020 23:37:12 +0000

Jim Reid <[email-masked]> wrote:

> Could the people on this thread *please* trim their postings?

Yes, more RFC 1855, please!

Tony.
-- 
           .-_|\    f.anthony.n.finch
          /     \      <[email-masked]>
McQuary ->*.--._/    http://dotat.at/
               v