Subject: Re: [Last-Call] [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

From: "Martin Thomson" <[email-masked]>
Date: Thu, 02 Jan 2020 12:03:38 +1100

On Thu, Dec 19, 2019, at 02:06, Sara Dickinson wrote:
> To try to separate out the issue with the text in Section 3.5.1.1 I’ll 
> respond to the comments on that in a separate thread and try to address 
> the other issues in this email. 

Ack.  Ekr's answer will suffice for mine there.

> > BTW, what is "HTTPS destination IP address fingerprinting"? Was the intent of this paragraph to say that this document only examines the DNS protocol independent of the greater context in which it is used? That is, it looks at DNS without considering how privacy risks might result from the use of DNS in combination with other protocols?
> 
> It is describing the ability to fingerprint the website a user connects 
> to based just on the IP address of the HTTPS traffic. For example, this 
> paper given at ANRW https://dl.acm.org/authorize?N687437. Please 
> suggest text if you prefer a different description of this issue.

Given that I don't know what the intent of your statement is, I can't really suggest anything.  However, if the intent is to refer to the paper, then do so.  You are using what appears to be a term or proper name with the expectation that it is understood, but that clearly isn't the case.

> Suggest:
> 
> OLD:
> “The use of clear text transport options to decrease latency may also 
> identify a user e.g. using TCP Fast Open [RFC7413]."
> 
> NEW:
> “Note that even when using encrypted transports the use of clear text 
> transport options to decrease latency can provide correlation of a 
> users' connections e.g. using TCP Fast Open [RFC7413].”

I don't think that really addresses the central point, namely that these options trade linkability for performance and need to do so based on the client's policies with respect to linkability.  TFO is something of a bad example because it offers no prospects for confidentiality protection and it seems like it is not likely to be widely deployed (for that privacy reason and several others related to deployment challenges).

> NEW:
> “Implementations that support encrypted transports are also highly 
> likely to re-use sessions for multiple DNS queries to optimize 
> performance (e.g. via DNS pipelining or HTTPS multiplexing). Default 
> configuration options for encrypted transports could in principle 
> fingerprint a specific client application. For example:…
> 
> If libraries or applications offer user configuration of such options 
> (e.g. [stubby]) then they could in principle help to identify a 
> specific user.”

If you want the most superficial treatment of the issue, sure.  A proper treatment of the issue would require a more dramatic change.  For instance:

   These are cases where user identification, fingerprinting or
   correlations may be possible due to the use of certain transport
   layers or clear text/observable features.  These issues are not
   specific to DNS, but DNS traffic is susceptible to these attacks when
   using specific transports.

Could become:

   The manner in which endpoints implement different protocols might offer the ability for a network-based observer to correlate activity from the same implementation.  This is not regarded as a serious problem, as the resulting anonymity set is increases with the number of deployments of the same stack.  Furthermore, DNS usages might then share an anonymity set with other protocols.

   However, individualized customization of stack operation could enable fingerprinting.  Implementations that offer the ability to alter default options for the operation of the unprotected parts of a stack risk creating smaller anonymity sets.

I'll point out that all the discussion of altering HTTP behaviour for DoH, such as cookies, makes it less likely that DoH will look like something else.  If endpoints simply had a framework for understanding when linkability is and isn't tolerable, then this would be far less problematic.  I'll note that browsers already have this framework. That's why you don't see browser people in the group of concerned citizens.  We all know that the framework is terrible in certain ways, but we understand its limitations and they are an area of active work.

> > Section 3.5.1.2
> RFC7626 included Section 2.5.3 
> https://tools.ietf.org/html/rfc7626#section-2.5.3 ‘Rogue Servers’. This 
> section is just an update of that text to improve context and remove 
> the phrase ’rogue server’. Since the majority of OS implementations 
> still use these mechanisms today it seems to still be relevant. 

Oh, I see that now.  Yeah, 7626s2.5.3 makes one very important point: it acknowledges the possibility for a server to abuse its privileged position.    I failed to link this to that text because this section only contains the other bits.

Those other bits are just a re-iteration of the failings of various discovery methods.  I think you will find that these limitations are acknowledged in the specifications for those protocols.  They aren't in the threat model for those protocols.

The point is that we're trusting the network to provide this service when we have no strong basis for trusting that the network is able to do so.

So maybe the answer here is to say:

  Stub resolvers that discover a resolver identity using the network are trusting the network to both operate a recursive resolver and to secure the discovery process.  That is, in addition to exposing queries to the network operator, vulnerabilities in the discovery process might allow an attacker to interpose their own resolver.  Note that DHCP assumes that the network provides certain safeguards; see Section 22 of [RFC8415].  [[include examples here]]

  Failing to authenticate and authorize a recursive resolver also exposes stub resolvers to the possibility of attack; see Section 3.5.1.4. Automatic discovery without any prior expectations about the identity of allowed resolver makes authorization impossible.

(inline text on authorization as you suggested.)

I would point out that the citation for dnschanger violates the standard assumptions in RFC 3514, so I wouldn't rely on that so much.  The ARP/NDP examples are in direct contradiction to the additional assumptions that DHCP makes.

> > Section 3.5.1.3
> NEW:
> “ Many network operators argue that they block access to remote 
> resolvers for security reasons, for example to cripple malware and bots 
> or to prevent data exfiltration methods that use encrypted DNS 
> communications as transport. Further discussion of Internet service 
> blocking and filtering can be found in [RFC7754]."

How about avoiding "argue that" and the associated rationale (your choice of words here has the unfortunate effect of promulgating an argument about efficacy that is almost certainly true today, but still steps into the debate) and instead stick to facts:

   As a matter of policy, some recursive resolvers use their position in the query path to selectively block access to certain records.  This is a form of Rendezvous-Based Blocking as described in Section 4.3 of [RFC7754].  In order to prevent circumvention of their blocking policies, some networks also block access to resolvers with incompatible policies.

FWIW, the title of this section might be problematic.  This isn't "user-selected", especially in the malware case.

> > Section 3.5.1.5.1
> > 
> > The arguments here repeat those from Section 3.4.2 (nit: not 3.4 as stated). A section reference would be enough.
> 
> I’ll update the section reference and remove the last sentence and the 
> two bullet points. 
> 
> > 
> > Section 3.5.1.5.2
> NEW:
> “Users should be aware that the particular choice of HTTPS 
> functionality vs data minimisation (for example, whether to include the 
> user-agent header) is an implementation specific choice in DoH, not one 
> defined in RFC8484.”

Who is the audience for this document again?

That doesn't really address my more general concerns.  For instance, I might take offense at:

>  the wide practice in HTTP to use various headers to optimize HTTP connections, functionality and behaviour (which can facilitate user identification and tracking)

on the basis that it assumes that these optimizations are deployed without regard to privacy.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Jan 2020 18:37:38 +0000

> On 19 Dec 2019, at 02:09, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On 2 Dec 2019, at 00:00, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:

<snip>

> 
> Suggest replacing the last 4 paragraphs of this section with the following text. 
> 
> I can't say I like this very much.
> 
> “It has been pointed out that should the trend towards using large public resolvers increase, an increased centralisation of DNS resolution services will result. 
> 
> Well, it's been pointed out, but it's not at all clear that it's true, due to the large amount of centralization of ISPs in certain areas, so no, I don't think this document should make this claim.

To address the more general problem I suggest:

“Should the trend away from using ISP managed resolvers to using a small set of large public resolvers continue, then an increased proportion of the global DNS resolution traffic will to be served by only a few entities. Some potential impacts of centralisation within the Internet Infrastructure are outlined in [I-D.draft-arkko-arch-infrastructure-centralisation] and include some privacy related considerations. "

> 
> 
> An increasing number of applications are offering application-specific encrypted DNS resolution settings, rather than defaulting to using only the system resolver. Due to a lack of a standardized discovery mechanism for DoH and Strict DoT servers, applications that do so are currently limited to using hard coded lists of resolvers and a variety of heuristics and resolvers are available in different applications. At the time of writing, efforts to provide standardized signalling mechanisms for applications to also discover the services offered by local resolvers are in progress [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of ISPs are deploying encrypted DNS, for example see the Encrypted DNS Deployment Initiative [EDDI].
> 
> I'm not sure what the point of this text is, but it seems kind of confusing. In particular, it's not the case that the primary reason that Firefox uses a hardcoded list is because there is no standardized discovery mechanism. 

To clarify I suggest: 

“An increasing number of applications are offering application-specific encrypted DNS resolution settings, rather than defaulting to using only the system resolver. A variety of heuristics and resolvers are available in different applications including hard-coded lists of recognised DoH/DoT servers.

There is currently no standardized discovery mechanism for DoH and Strict DoT servers so applications that might want to dynamically discover such encrypted services are not able to. At the time of writing, efforts to provide standardized signalling mechanisms for applications to also discover the services offered by local resolvers are in progress [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of ISPs are deploying encrypted DNS, for example see the Encrypted DNS Deployment Initiative [EDDI]."

> 
> Everything after this just seems to pre-empt discussions that are ongoing and haven't reached consensus.
> 
> 
> Application-specific changes to default destinations for users' DNS queries might increase or decrease user privacy - it is highly dependant on the network context and the application-specific default. This is an area of active debate.
> 
> In order that users are aware of and can control such changes it is highly desirable that applications
> * communicate clearly the change in default to users
> * provide configuration options to change the default
> * provide configuration options to always use the network provided resolver
> 
> The IETF is working on a number of issues related to application-specific DNS settings. For example there have been discussions on the IETF ADD mailing list [ADD] and a proposal for a new ABCD working group [ABCD].”

The goal here is to make the readers of the document aware of ongoing work even where consensus isn’t reached, which I think the first and third paragraphs do. The bullet points are meant to raise user awareness so if you really feel it necessary I propose changing the text as follows

OLD: “In order that users are aware of and can control such changes it is highly desirable that applications"

NEW: “Users will only be aware of and have the ability to control such changes if applications provide the following functions:”

Attempting to stick to be factual here rather an asserting anything anything about consensus. Please suggest text if you have a better description of the issue.

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Jan 2020 18:37:52 +0000

> On 19 Dec 2019, at 04:05, Rob Sayre <[email-masked]> wrote:
> 
> 
> 
> On Wed, Dec 18, 2019 at 6:10 PM Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Agree.
> The text also relates discovery to encryption. That seems odd. Is it the case that some parties didn't mind which DNS server was used, as long as the traffic was unencrypted?

> Is it "highly desirable", though?
>  
> Not clearly true, since the status quo is often not clearly communicated.
>  
> Doesn't seem like that is always desirable. Some routers and networks don't offer configuration options, but that doesn't mean they should be obeyed. It's complicated.

For both the above points please see the response to Ekr.

> "network provided resolver" is not well-defined.

Suggest “DHCP-provided resolver” which is used earlier in the section. 

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Jan 2020 18:38:34 +0000

> On 31 Dec 2019, at 14:45, Eric Rescorla <[email-masked]> wrote:
> 
> 

> On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> Prompted by my surprise at seeing Brian Trammell's mention of a '[firefox]' reference in this document, I reviewed the contents of this draft more closely.
>> 
>> Summary
>> 
>> I found a number of issues with the additions in this -bis document.  Of particular concern is Section 3.5.1 (formerly Section 2.5.1 in RFC 7626), which has been expanded from one paragraph to four pages.  That there is a need for new content here is clear.  One thing that has become very clear is that our understanding of the role of recursive resolvers has evolved a lot in the past year.  However, I don't believe that the current text is a fair representation of the problems we're facing.  Right now, the community is in the middle of highly contentious debate on the general topic, and I don't think that the new content reflects consensus.
>> 
>> It does appear as though there is an attempt here to address the invariant technical characteristics without engaging more controversial positions.  I don't believe that has been successful.  The effect is to preempt an active area of contention.
>> 
>> I am opposed to the IETF publishing this document in its current form.
>> 
> 
> Martin, 
> 
> To try to separate out the issue with the text in Section 3.5.1.1 I’ll respond to the comments on that in a separate thread and try to address the other issues in this email. 
> 
>> 
>> Section 2
>> 
>>> This document does not attempt a comparison of specific privacy protections provided by individual networks or organisations, it makes only general observations about typical current practices.
>> 
>> Having been called out here, I would question whether this claim is indeed correct.
>> 
> It is describing the ability to fingerprint the website a user connects to based just on the IP address of the HTTPS traffic. For example, this paper given at ANRW https://dl.acm.org/authorize?N687437 <https://dl.acm.org/authorize?N687437>.  Please suggest text if you prefer a different description of this issue.
> 
> Ah, well, then I certainly wouldn't call this HTTPS-anything, given that it's a feature of basically every protocol. It just comes up more in the HTTPS context because we're otherwise encrypting the traffic.
> 
> I would say
> "The privacy risks associated with other protocols that make use of DNS information are not considered here”

That works.

> 
> 
>> 
>> Section 3.4.2
>> 
>> This section appears to address several related issues around the use of TLS primarily: fingerprinting, identification, and linkability (the document uses the word "correlation" in line with RFC 6973).  There are parts where fingerprinting is equated with identification or linkability in ways that appear confused.
>> 
>> For instance,
>> 
>>> The use of clear text transport options to optimize latency may also identify a user, e.g., using TCP Fast Open with TLS 1.2 [RFC7413].
>> 
>> The use of TFO is a linkability issue, not an identification one.  TFO can also be used without encrypted transport.
>> 
>> However, this seems overly negative. Resumption and TFO cookies - and therefore any linkability they might provide - is discretionary on the part of clients. You might (as is done later) raise the question here about the competing concerns of individuals and implementations, but that's a meta-level question that I'll get back to.
>> 
>> As a minor note here, TLS 1.3 resumption also provides a server with the ability to link sessions.  This document seems to assume that this is a property of TLS 1.2 only, which is incorrect.  There are proposals that might allow for unlinkable resumption, but those are still just proposals.
> 
> Suggest:
> 
> OLD:
> “The use of clear text transport options to decrease latency may also identify a user e.g. using TCP Fast Open [RFC7413]."
> 
> NEW:
> “Note that even when using encrypted transports the use of clear text transport options to decrease latency can provide correlation of a users' connections e.g. using TCP Fast Open [RFC7413].”
> 
> Sure.
> 
> 
>> 
>> Also on linkability and identification:
>> 
>>> Certain configuration options for encrypted transports could also in principle fingerprint a user or client application.
>> 
>> Though there are definitely ways in which the listed options contribute to fingerprinting, the paragraph talks about session resumption, where the concern is primarily linkability.  Mixing these concepts only serves to confuse rather than enlighten.
>> 
>> When it comes to fingerprinting, it's important to distinguish between an ability to identify the software in use (Windows vs. Linux, Safari vs. Chrome) and the ability to distinguish different users.  The text here conflates these notions in an unhelpful fashion. The fingerprinting highlighted is a result of characteristics inherent to the software, not user-specific details.
>> 
>> For the most part, we (as protocol designers) accept that distinguishing software is possible and we don't generally attempt to erase differences that only serve to reinforce those signals. Suppressing differences in wire image across implementations generally runs counter to the desire for diversity in implementation choices.  This text - perhaps unintentionally - takes the somewhat sensational position that distinguishing between FreeBSD and Solaris is as relevant as the sort of fingerprinting that might be used to isolate individuals.  It does that by concentrating on choices that are usually made by implementations not individuals.
>> 
>> This is where a clear recognition of the distinction between implementation choices and how implementations represent (or maybe don't represent, if that is the way you feel) the choices of individuals requires a little more care.  I don't know how easy it is to engage on that topic without also engaging with the current debate though.
> 
> Suggest:
> 
> OLD:
> “Users of encrypted transports are also highly likely to re-use sessions for multiple DNS queries to optimize performance (e.g. via DNS pipelining or HTTPS multiplexing). Certain configuration options for encrypted transports could also in principle fingerprint a user or client application.  For example: …."
> 
> NEW:
> “Implementations that support encrypted transports are also highly likely to re-use sessions for multiple DNS queries to optimize performance (e.g. via DNS pipelining or HTTPS multiplexing). Default configuration options for encrypted transports could in principle fingerprint a specific client application. For example:…
> 
> I don't generally think that documents like this ought to predict how implementers will behave, so I would remove this text entirely.

But one of the points of this document is to describe the actual use of DNS so discussing implementation behaviour seems within scope. Given many of the implementations of DoT are done by DNS developers who might be implementing TLS for the first time highlighting potential privacy considerations with such implementation choices also seems relevant. 

> 
> On the surface, this actually seems like quite a good setting for *not* using TLS session resumption (or TFO, or 0-RTT). Consider a browser, in which you're likely going to want to connect to the DoH server on startup and keep that connection open as long as you are doing just about anything that would cause DNS resolution. You might disconnect when you go really idle, but then you could get warm again quickly when the user re-engages, at which point you probably can just accept an extra RT (remember that user response is quite slow). This isn't something that we have spent a lot of time optimizing, I don't think, so I suspect there's still a fair bit of work to do to figure out the best pattern. In any case, making recommendations here seems premature.

Where is a recommendation made? I _think_ the text just describes the issue - please suggest text otherwise.

I agree with Vittorio’s follow up comment about at least including a description of the issue - the abstract of this document states “It is intended to be an analysis of the present situation and does not prescribe solutions. "

> 
> 
> If libraries or applications offer user configuration of such options (e.g. [stubby]) then they could in principle help to identify a specific user.”
> 
> This seems true, but TBH kind of a niche case. General experience is that people don't change defaults very much, so the real guidance is "don't change defaults so you can hide in the crowd”

Suggest adding “Users may want to avoid changing such options to avoid this issue."

> 
> 
>> 
>> Section 3.5.1.2
>> 
>> I admit that I don't understand the purpose of this section. Concentrating on minutiae, like the details of DHCP or ARP/NDP spoofing, is far too low level. If we were to simply assume the usual threat model [RFC3552], then the conclusions here are obvious: if you fail to authenticate the server, then you get the server that an attacker chooses.
>> 
>> I would remove this section in favour of improving Section 3.5.1.4, which addresses the most pertinent question.
> 
> RFC7626 included Section 2.5.3 https://tools.ietf.org/html/rfc7626#section-2.5.3 <https://tools.ietf.org/html/rfc7626#section-2.5.3> ‘Rogue Servers’. This section is just an update of that text to improve context and remove the phrase ’rogue server’.  Since the majority of OS implementations still use these mechanisms today it seems to still be relevant. 
> 
> Well, as MT says, this is just the 3552 threat model.  The basic fact is that you need a reference to a server that is (1) securely obtained and (2) verifiable against the server itself. Absent that, you are subject to attack by the network.

Suggest adding a sentence at the start of the section “[RFC3552] provides guidelines for describing Internet threat models. This section specialises the discussion to the case of DNS resolver configuration.”

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Jan 2020 18:39:14 +0000

> On 31 Dec 2019, at 22:35, Rob Sayre <[email-masked]> wrote:
> 
> Suggest the following text with the goal of getting consensus that the opinion exists and is held by many network operators, not that the opinion itself has consensus:
> 
> OLD:
> “ In some cases, networks might block access to remote resolvers for security reasons, for example to cripple malware and bots or to prevent data exfiltration methods that use encrypted DNS communications as transport.  In these cases, if the network fully respects user privacy in other ways (i.e.  encrypted DNS and good data handling policies) the block can serve to further protect user privacy by ensuring such security precautions."
> 
> NEW:
> “ Many network operators argue that they block access to remote resolvers for security reasons, for example to cripple malware and bots or to prevent data exfiltration methods that use encrypted DNS communications as transport.  Further discussion of Internet service blocking and filtering can be found in [RFC7754]."
> 
> Well, this is a new form of "many people are saying..." to me. I sent a few messages about specific sections of this document, which are yet to be addressed, but I also think the entire document is misguided and shouldn't be published.
> 
> It seems to contain a lot of "both sides" rhetoric that is ungrounded in technical matters, and not appropriate for the IETF to publish.
> 
> For example, a reasonable person might look at ways of preventing and/or uninstalling malware rather than relying on DNS to block it.

I think you misunderstood the point of the document. As the abstract says “It is intended to be an analysis of the present situation and does not prescribe solutions.“ The original RFC was published on this basis, this document just extends the analysis. 

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Jan 2020 18:39:18 +0000

> On 2 Jan 2020, at 01:03, Martin Thomson <[email-masked]> wrote:
> 

Propose using text suggest by Ekr here: "The privacy risks associated with other protocols that make use of DNS information are not considered here"

> I don't think that really addresses the central point, namely that these options trade linkability for performance and need to do so based on the client's policies with respect to linkability.  TFO…

Several DNS implementations support TFO which was one of the reasons to include this. 

> I'll point out that all the discussion of altering HTTP behaviour for DoH, such as cookies, makes it less likely that DoH will look like something else.  If endpoints simply had a framework for und…

That works for HTTPS folks but I think this text needs to speak to the DNS community who are from a UDP mindset. The current level of treatment was sufficient for the draft to pass WGLC so I would be minded to keep it at that level. 

> (inline text on authorization as you suggested.)

You might be over thinking this section. The text is highlighting the methods of attack used but focussing on the practical consequences of the attack for the DNS resolution. I agree some of the text is useful as background though so would suggest inserting the following after the first paragraph

“The majority of currently deployed stub resolvers use DHCP to discover the identities of resolvers provided by the local network and use no additional authentication mechanism to validate the resolver. The stub therefore places trust in the network to both operate a recursive resolver and to secure the discovery process. Note that DHCP assumes that the network provides certain safeguards; see Section 22 of [RFC8415]. Vulnerabilities in the discovery process might allow an attacker to interpose their own resolver as described below. "

>   As a matter of policy, some recursive resolvers use their position in the query path to selectively block access to certain records.  This is a form of Rendezvous-Based Blocking as described in S…

Agree on sticking to the facts but I think the reason for the blocking is key for readers of this document to fully understand the current situation. How about: 

“As a matter of policy, some recursive resolvers use their position in the query path to selectively block access to certain DNS records.  This is a form of Rendezvous-Based Blocking as described in Section 4.3 of [RFC7754]. Such blocklists often include servers know to be used for malware, bots or other security risks. In order to prevent circumvention of their blocking policies, some networks also block access to resolvers with incompatible policies. "

> FWIW, the title of this section might be problematic.  This isn't "user-selected", especially in the malware case.

Suggest “Blocking of User Selected DNS Resolution Services”. 

> Who is the audience for this document again?

I think it has a very wide audience, anyone who want to understand the privacy considerations of actually using the DNS on the Internet. 

Suggest: 

“the wide practice in HTTP to use various headers to optimize HTTP connections, functionality and behaviour which can introduce a trade-off between functionality and privacy (since it can facilitate user identification and tracking)”

Sara.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Jan 2020 14:47:02 -0800

On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson <[email-masked]> wrote:

> On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson <[email-masked]> wrote:
>
>>
>>
>> > On 2 Dec 2019, at 00:00, Martin Thomson <[email-masked]> wrote:
>>
>
> <snip>
>
>
>> “It has been pointed out that should the trend towards using large public
>> resolvers increase, an increased centralisation of DNS resolution services
>> will result.
>>
>
> Well, it's been pointed out, but it's not at all clear that it's true, due
> to the large amount of centralization of ISPs in certain areas, so no, I
> don't think this document should make this claim.
>
>
> “Should the trend away from using ISP managed resolvers to using a small
> set of large public resolvers continue, then an increased proportion of the
> global DNS resolution traffic will to be served by only a few entities.
> Some potential impacts of centralisation within the Internet Infrastructure
> are outlined in [I-D.draft-arkko-arch-infrastructure-centralisation] and
> include some privacy related considerations. "
>

Yeah, my point is that I don't agree with this. Right now there is a lot of
ISP centralization and the move of some of that traffic to public resolvers
potentially decreases centralization at the margin. I certainly don't agree
with citing draft-arkko, which is not at all a neutral or factual source,
so this is just a way of incorporating by reference material which doesn't
have consensus.

An increasing number of applications are offering application-specific
>> encrypted DNS resolution settings, rather than defaulting to using only the
>> system resolver. Due to a lack of a standardized discovery mechanism for
>> DoH and Strict DoT servers, applications that do so are currently limited
>> to using hard coded lists of resolvers and a variety of heuristics and
>> resolvers are available in different applications. At the time of writing,
>> efforts to provide standardized signalling mechanisms for applications to
>> also discover the services offered by local resolvers are in progress
>> [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of
>> ISPs are deploying encrypted DNS, for example see the Encrypted DNS
>> Deployment Initiative [EDDI].
>>
>
> I'm not sure what the point of this text is, but it seems kind of
> confusing. In particular, it's not the case that the primary reason that
> Firefox uses a hardcoded list is because there is no standardized discovery
> mechanism.
>
>
> To clarify I suggest:
>
> “An increasing number of applications are offering application-specific
> encrypted DNS resolution settings, rather than defaulting to using only the
> system resolver. A variety of heuristics and resolvers are available in
> different applications including hard-coded lists of recognised DoH/DoT
> servers.
>
> There is currently no standardized discovery mechanism for DoH and Strict
> DoT servers so applications that might want to dynamically discover such
> encrypted services are not able to. At the time of writing, efforts to
> provide standardized signalling mechanisms for applications to also
> discover the services offered by local resolvers are in progress
> [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of
> ISPs are deploying encrypted DNS, for example see the Encrypted DNS
> Deployment Initiative [EDDI]."
>

I don't object to this text, but what's the point?

Everything after this just seems to pre-empt discussions that are ongoing
> and haven't reached consensus.
>
>
>> Application-specific changes to default destinations for users' DNS
>> queries might increase or decrease user privacy - it is highly dependant on
>> the network context and the application-specific default. This is an area
>> of active debate.
>>
>> The IETF is working on a number of issues related to application-specific
>> DNS settings. For example there have been discussions on the IETF ADD
>> mailing list [ADD] and a proposal for a new ABCD working group [ABCD].”
>>
>
>
> The goal here is to make the readers of the document aware of ongoing work
> even where consensus isn’t reached, which I think the first and third
> paragraphs do. The bullet points are meant to raise user awareness so if
> you really feel it necessary I propose changing the text as follows
>
> NEW: “Users will only be aware of and have the ability to control such
> changes if applications provide the following functions:”
>
> Attempting to stick to be factual here rather an asserting anything
> anything about consensus. Please suggest text if you have a better
> description of the issue.
>

My position is you should strike this text, not attempt to rewrite it. In
general, the history of trying to neutrally document controversial issues
in IETF is not very encouraging, and in this case it's quite unnecesary.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Jan 2020 14:51:43 -0800

On Tue, Jan 7, 2020 at 10:38 AM Sara Dickinson <[email-masked]> wrote:

> On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson <[email-masked]> wrote:
>
>>
>>
>> Prompted by my surprise at seeing Brian Trammell's mention of a
>> '[firefox]' reference in this document, I reviewed the contents of this
>> draft more closely.
>>
>> Summary
>>
>> I found a number of issues with the additions in this -bis document.  Of
>> particular concern is Section 3.5.1 (formerly Section 2.5.1 in RFC 7626),
>> which has been expanded from one paragraph to four pages.  That there is a
>> need for new content here is clear.  One thing that has become very clear
>> is that our understanding of the role of recursive resolvers has evolved a
>> lot in the past year.  However, I don't believe that the current text is a
>> fair representation of the problems we're facing.  Right now, the community
>> is in the middle of highly contentious debate on the general topic, and I
>> don't think that the new content reflects consensus.
>>
>> It does appear as though there is an attempt here to address the
>> invariant technical characteristics without engaging more controversial
>> positions.  I don't believe that has been successful.  The effect is to
>> preempt an active area of contention.
>>
>> respond to the comments on that in a separate thread and try to address the
>> other issues in this email.
>>
>>
>> Section 2
>>
>> This document does not attempt a comparison of specific privacy
>> protections provided by individual networks or organisations, it makes only
>> general observations about typical current practices.
>>
>>
>> BTW, what is "HTTPS destination IP address fingerprinting"?  Was the
>> intent of this paragraph to say that this document only examines the DNS
>> protocol independent of the greater context in which it is used?  That is,
>> it looks at DNS without considering how privacy risks might result from the
>> use of DNS in combination with other protocols?
>>
>>
> Ah, well, then I certainly wouldn't call this HTTPS-anything, given that
> it's a feature of basically every protocol. It just comes up more in the
> HTTPS context because we're otherwise encrypting the traffic.
>
> I would say
>> This section appears to address several related issues around the use of
>> TLS primarily: fingerprinting, identification, and linkability (the
>> document uses the word "correlation" in line with RFC 6973).  There are
>> parts where fingerprinting is equated with identification or linkability in
>> ways that appear confused.
>>
>> For instance,
>>
>> The use of clear text transport options to optimize latency may also
>> identify a user, e.g., using TCP Fast Open with TLS 1.2 [RFC7413].
>>
>>
>> The use of TFO is a linkability issue, not an identification one.  TFO
>> can also be used without encrypted transport.
>>
>> However, this seems overly negative. Resumption and TFO cookies - and
>> therefore any linkability they might provide - is discretionary on the part
>> of clients. You might (as is done later) raise the question here about the
>> competing concerns of individuals and implementations, but that's a
>> meta-level question that I'll get back to.
>>
>> As a minor note here, TLS 1.3 resumption also provides a server with the
>> ability to link sessions.  This document seems to assume that this is a
>> property of TLS 1.2 only, which is incorrect.  There are proposals that
>> might allow for unlinkable resumption, but those are still just proposals.
>>
>>
>> Suggest:
>>
>> OLD:
>> transport options to decrease latency can provide correlation of a users'
>> connections e.g. using TCP Fast Open [RFC7413].”
>>
>
> Sure.
>
>
>
>> Certain configuration options for encrypted transports could also in
>> principle fingerprint a user or client application.
>>
>>
>> Though there are definitely ways in which the listed options contribute
>> to fingerprinting, the paragraph talks about session resumption, where the
>> concern is primarily linkability.  Mixing these concepts only serves to
>> confuse rather than enlighten.
>>
>> When it comes to fingerprinting, it's important to distinguish between an
>> ability to identify the software in use (Windows vs. Linux, Safari vs.
>> Chrome) and the ability to distinguish different users.  The text here
>> conflates these notions in an unhelpful fashion. The fingerprinting
>> highlighted is a result of characteristics inherent to the software, not
>> user-specific details.
>>
>>
>> For the most part, we (as protocol designers) accept that distinguishing
>> software is possible and we don't generally attempt to erase differences
>> that only serve to reinforce those signals. Suppressing differences in wire
>> image across implementations generally runs counter to the desire for
>> diversity in implementation choices.  This text - perhaps unintentionally -
>> takes the somewhat sensational position that distinguishing between FreeBSD
>> and Solaris is as relevant as the sort of fingerprinting that might be used
>> to isolate individuals.  It does that by concentrating on choices that are
>> usually made by implementations not individuals.
>>
>> This is where a clear recognition of the distinction between
>> implementation choices and how implementations represent (or maybe don't
>> represent, if that is the way you feel) the choices of individuals requires
>> a little more care.  I don't know how easy it is to engage on that topic
>> without also engaging with the current debate though.
>>
>>
>> Suggest:
>>
>> OLD:
>> “Users of encrypted transports are also highly likely to re-use sessions
>> for multiple DNS queries to optimize performance (e.g. via DNS pipelining
>> or HTTPS multiplexing). Certain configuration options for encrypted
>> transports could also in principle fingerprint a user or client
>> application.  For example: …."
>>
>> NEW:
>> “Implementations that support encrypted transports are also highly likely
>> to re-use sessions for multiple DNS queries to optimize performance (e.g.
>> via DNS pipelining or HTTPS multiplexing). Default configuration options
>> for encrypted transports could in principle fingerprint a specific client
>> application. For example:…
>>
>
> I don't generally think that documents like this ought to predict how
> implementers will behave, so I would remove this text entirely.
>
>
> But one of the points of this document is to describe the actual use of
> DNS so discussing implementation behaviour seems within scope. Given many
> of the implementations of DoT are done by DNS developers who might be
> implementing TLS for the first time highlighting potential privacy
> considerations with such implementation choices also seems relevant.
>

There are two problems here:

1. That you are making predictions about what people will do and that those
preductions are unsupported by evidence. That needs to go.
2. That you are covering material that is already better covered in 8484,
so why are you duplicating it?

> On the surface, this actually seems like quite a good setting for *not*
> using TLS session resumption (or TFO, or 0-RTT). Consider a browser, in
> which you're likely going to want to connect to the DoH server on startup
> and keep that connection open as long as you are doing just about anything
> that would cause DNS resolution. You might disconnect when you go really
> idle, but then you could get warm again quickly when the user re-engages,
> at which point you probably can just accept an extra RT (remember that user
> response is quite slow). This isn't something that we have spent a lot of
> time optimizing, I don't think, so I suspect there's still a fair bit of
> work to do to figure out the best pattern. In any case, making
> recommendations here seems premature.
>
>
> I agree with Vittorio’s follow up comment about at least including a
> description of the issue - the abstract of this document states “It is
> intended to be an analysis of the present situation and does not prescribe
> solutions. "
>

To repeat my question from before: this material is already in 8484, so why
are you trying to write a new document that duplicates that?

>> (e.g. [stubby]) then they could in principle help to identify a specific
>> user.”
>>
>
> This seems true, but TBH kind of a niche case. General experience is that
> people don't change defaults very much, so the real guidance is "don't
> change defaults so you can hide in the crowd”
>
>

Sure, OK.

>
>
>
>> Section 3.5.1.2
>>
>> I admit that I don't understand the purpose of this section.
>> Concentrating on minutiae, like the details of DHCP or ARP/NDP spoofing, is
>> far too low level. If we were to simply assume the usual threat model
>> [RFC3552], then the conclusions here are obvious: if you fail to
>> authenticate the server, then you get the server that an attacker chooses.
>>
>> section is just an update of that text to improve context and remove the
>> phrase ’rogue server’.  Since the majority of OS implementations still use
>> these mechanisms today it seems to still be relevant.
>>
>
> Well, as MT says, this is just the 3552 threat model.  The basic fact is
> that you need a reference to a server that is (1) securely obtained and (2)
> verifiable against the server itself. Absent that, you are subject to
> attack by the network.
>
>
> Suggest adding a sentence at the start of the section “[RFC3552] provides
> guidelines for describing Internet threat models. This section specialises
> the discussion to the case of DNS resolver configuration.”
>

Well, that's a start, but the problem is still that it's too low level. If
you insist on having this section, you should lay out the implications of
the situation rather than (or at least in advance of) digging into the
details.

-Ekr

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 08 Jan 2020 15:15:15 +1100

This thread is starting to get hard for me to follow.  Apologies if something goes missing.

On Wed, Jan 8, 2020, at 05:39, Sara Dickinson wrote:
> Propose using text suggest by Ekr here: "The privacy risks associated 
> with other protocols that make use of DNS information are not 
> considered here"

ACK.  WFM.

> Several DNS implementations support TFO which was one of the reasons to 

Let me try to restate my point more clearly then: the choice to enable TFO implies a policy decision regarding linkability on the part of those who do that.  And to the extent that TFO is deployed, it deserves separate mention as it is somewhat exceptional.  What is currently implied is that TFO is exemplary of a class of linkability problems that you inherit when you move to something other than UDP, but that is not at all the case.

As I previously mentioned, most of the visible behaviour is taken from a small set of implementations, because these are often OS-level TCP implementation quirks that allow for some fingerprinting entropy to be gained by the observer.  The current framing creates a biased perception of the nature of the problem.

> That works for HTTPS folks but I think this text needs to speak to the 
> DNS community who are from a UDP mindset. The current level of 
> treatment was sufficient for the draft to pass WGLC so I would be 
> minded to keep it at that level. 

That was an aside explaining motivation.  I would rather talk about the substance of the suggestion and the need for a more nuanced treatment of the subject.  One of the strengths of IETF LC over WGLC is that is allows us to draw on wider perspectives and this is clearly a case that would benefit from that.

> “The majority of currently deployed stub resolvers use DHCP to discover 
> the identities of resolvers provided by the local network and use no 
> additional authentication mechanism to validate the resolver. The stub 
> therefore places trust in the network to both operate a recursive 
> resolver and to secure the discovery process. Note that DHCP assumes 
> that the network provides certain safeguards; see Section 22 of 
> [RFC8415]. Vulnerabilities in the discovery process might allow an 
> attacker to interpose their own resolver as described below. "

> > I would point out that the citation for dnschanger violates the standard assumptions in RFC 3514, so I wouldn't rely on that so much.  The ARP/NDP examples are in direct contradiction to the addi…

This isn't a question of framing as much as it saying that the specific text on vulnerabilities is directly at odds with the security models assumed by the discovery protocols.

That makes the expansion of these details of questionable value outside of saying that not all network deployments meet the requirements for DHCP deployment and so are vulnerable to attack on the discovery process, which is what enables things like dnschanger and so on.  I'd be happy to add that even if discovery is secured, failing to secure interactions with the DNS server adds further vulnerability to attack.  But this doesn't need to talk about how, because there isn't one single way.

> “As a matter of policy, some recursive resolvers use their position in 
> the query path to selectively block access to certain DNS records.  
> This is a form of Rendezvous-Based Blocking as described in Section 4.3 
> of [RFC7754]. Such blocklists often include servers know to be used for 
> malware, bots or other security risks. In order to prevent 
> circumvention of their blocking policies, some networks also block 
> access to resolvers with incompatible policies. "

WFM, and the title change.

> I think it has a very wide audience, anyone who want to understand the 
> privacy considerations of actually using the DNS on the Internet. 

Sorry, that was a little snarky.  There are two problems here: the assumption that user awareness is the right approach to addressing privacy concerns. That I am aware of a terrible practice is not always sufficient, though it might be necessary. More seriously, the broad-strokes implication that HTTP capabilities naturally result in having to trade some aspect of functionality (performance, operational advances, whatever) against privacy.  That's a thematic problem with this document.  I don't think that it is fair to say that it is FUD, but it could do better to recognize that there are effective tools for managing this particular class of problem.

Yes, there are cases where functionality has been added that depends on providing some degree of linkability between requests.  Connection reuse is one place where DNS and HTTP have this property in common.

But it is true that HTTP has grown a number (many) of similar features.  You could - as this document strong implies - suggest that multitude of options makes it a risky proposition to use HTTP because of the surprising ways in which linkability manifests.  Or, you could recognize that you need a framework from within which to simplify the analysis.  And that these features were developed within existing frameworks that greatly simplified any privacy assessment.

That's considerably simpler than this document would seem to suggest: you just need to decide how to create clear separation between queries (or groups of queries).  For reference, to a first order approximation, the web segregates by origin in space and uses cookie clearing to segment in time.  That has enabled us to develop these capabilities without changing the privacy profile of the resulting system substantially.   Indeed, recognizing and formalizing this model has allowed us to make some significant privacy improvements on the web.

A privacy analysis of DNS that aimed to formalize a similar framework might be useful.  This might start by recognizing that source IP dominates any analysis.  This is recognized in the document, but it isn't developed beyond that.  It might be possible to look at existing practice here (client source port randomization seems to ensure that NAT provides some anonymity when UDP is used) and - based on that - to develop a framework for understanding the current bounds on linkability.  Then you could describe how aligning breaks in linkability all the way up the stack can be used to provide privacy gains: see https://tools.ietf.org/html/draft-wood-linkable-identifiers-01 for more background there.

For this document, at this point in time, it might be better to recognize that the problem exists and that current approaches for dealing with linkability are ad hoc and uncoordinated.  Then maybe say that the introduction of new transports requires a stronger shared understanding of what the exposure is and how that might be best managed.  My intuition is that there are significant gains to be had out of this more than there are new risks introduced by the new transports.

> “the wide practice in HTTP to use various headers to optimize HTTP 
> connections, functionality and behaviour which can introduce a 
> trade-off between functionality and privacy (since it can facilitate 
> user identification and tracking)”

How is that materially different?  See above regarding the implications about this trade-off.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 7 Jan 2020 20:27:37 -0800

On Tue, Jan 7, 2020 at 8:15 PM Martin Thomson <[email-masked]> wrote:

> But it is true that HTTP has grown a number (many) of similar features.
> You could - as this document strong implies - suggest that multitude of
> options makes it a risky proposition to use HTTP because of the surprising
> ways in which linkability manifests.  Or, you could recognize that you need
> a framework from within which to simplify the analysis.
>

Huh, is there actually a privacy bug in the DoH spec wrt privacy here?

Couldn't servers give out unique URI templates?

thanks,
Rob

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 Jan 2020 22:10:55 -1000

On 1/7/2020 12:47 PM, Eric Rescorla wrote:
>     “Should the trend away from using ISP managed resolvers to using a
>     small set of large public resolvers continue, then an increased
>     proportion of the global DNS resolution traffic will to be served
>     by only a few entities. Some potential impacts of centralisation
>     within the Internet Infrastructure are outlined in
>     [I-D.draft-arkko-arch-infrastructure-centralisation] and include
>     some privacy related considerations.. "
>
>
> Yeah, my point is that I don't agree with this. Right now there is a
> lot of ISP centralization and the move of some of that traffic to
> public resolvers potentially decreases centralization at the margin. I
> certainly don't agree with citing draft-arkko, which is not at all a
> neutral or factual source, so this is just a way of incorporating by
> reference material which doesn't have consensus.

Centralization manifests itself in many ways. EKR is correct that big
ISP do get a huge part of the traffic -- last time I checked, there was
at least one ISP in China and another in India that served pretty much
as many customers as Google DNS. There is also centralization at work
due to outsourcing of the DNS service by ISP. This is a classic
concentration path: an outsourcer that serves many ISP will achieve
economies of scale and may be able to monetize the data flow, making
outsourcing a viable option for the ISP. Experience predicts that
competition between these outsourcers will exhibit "winners take all"
dynamics leading to concentration. As EKR says, the move to third party
resolvers may well counter concentration in the back end of the network.
It could also achieve the opposite, but there are risks on both sides of
this issue. I don't see how we can achieve consensus that one side of
the risk is more dangerous than the other.

-- Christian Huitema

---

From: Neil Cook <[email-masked]>
Date: Wed, 8 Jan 2020 11:39:29 +0000

> On 8 Jan 2020, at 08:10, Christian Huitema <[email-masked]> wrote:
> 
> 
> 
>> “Should the trend away from using ISP managed resolvers to using a small set of large public resolvers continue, then an increased proportion of the global DNS resolution traffic will to be served by only a few entities. Some potential impacts of centralisation within the Internet Infrastructure are outlined in [I-D.draft-arkko-arch-infrastructure-centralisation] and include some privacy related considerations.. "
>> 
>> Yeah, my point is that I don't agree with this. Right now there is a lot of ISP centralization and the move of some of that traffic to public resolvers potentially decreases centralization at the margin. I certainly don't agree with citing draft-arkko, which is not at all a neutral or factual source, so this is just a way of incorporating by reference material which doesn't have consensus.
> 
> Centralization manifests itself in many ways. EKR is correct that big ISP do get a huge part of the traffic -- last time I checked, there was at least one ISP in China and another in India that served pretty much as many customers as Google DNS.
> 
I’m sure there are examples of certain regions where large ISPs control a large percentage of the traffic. However that does not change the argument that globally there are tens of thousands of ISPs, which users are free to choose between (I accept that in a few places, notably the US, there is sometimes no choice of which cable company you can use). Here in the UK there are over 100 ISPs I can choose from, almost all of whom run their own resolver. That is a vast difference from a small number of global centralised DNS providers.

The text proposed is pretty specific, i.e. "*if* the trend away from using ISP managed resolvers to using a small set of large public resolvers continue”. So if it turns out that there ends up being more public resolvers for end-users to choose from than there are ISPs running their own resolver, then great. However is anyone here really suggesting that there will be? The economics just don’t add up.
> There is also centralization at work due to outsourcing of the DNS service by ISP. This is a classic concentration path: an outsourcer that serves many ISP will achieve economies of scale and may be able to monetize the data flow, making outsourcing a viable option for the ISP.
> 
Outsourcing of the DNS service by an ISP is surely part of the “trend away from using ISP managed resolvers to a small set of large public resolvers”, and thus proves the point?
> Experience predicts that competition between these outsourcers will exhibit "winners take all" dynamics leading to concentration. As EKR says, the move to third party resolvers may well counter concentration in the back end of the network. It could also achieve the opposite, but there are risks on both sides of this issue. I don't see how we can achieve consensus that one side of the risk is more dangerous than the other.
> 
I see both of these being the same. I don’t see how they counter each other. Both are examples of centralisation.
> -- Christian Huitema
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 8 Jan 2020 12:42:22 +0100 (CET)

Il 08/01/2020 09:10 Christian Huitema <[email-masked]> ha scritto:

Centralization manifests itself in many ways. EKR is correct that big ISP do get a huge part of the traffic -- last time I checked, there was at least one ISP in China and another in India that served pretty much as many customers as Google DNS. There is also centralization at work due to outsourcing of the DNS service by ISP. This is a classic concentration path: an outsourcer that serves many ISP will achieve economies of scale and may be able to monetize the data flow, making outsourcing a viable option for the ISP. Experience predicts that competition between these outsourcers will exhibit "winners take all" dynamics leading to concentration. As EKR says, the move to third party resolvers may well counter concentration in the back end of the network. It could also achieve the opposite, but there are risks on both sides of this issue. I don't see how we can achieve consensus that one side of the risk is more dangerous than the other.

As I understood it, the purpose of the draft is to document all possible risks, and not necessarily to provide a consensus view on which ones are stronger or more important than others. Personally, I think that ISPs can "take all" on the scale of a single country/region but their "physicalness" makes it much harder for them to achieve dominance on a global scale, while third parties operating immaterial services over the network can more easily "take all" on a planetary level - but this is just a personal assessment, and I may just be wrong. So you could just state this view and the opposite one, and then the readers (the implementers using this as guidance) will then be free to decide which of these risks are more relevant to their use case, context and views of the world.

Thus I would suggest text that describes "both sides of the risk" and then leaves it to the readers to decide which one is more problematic for them.

--

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Jan 2020 04:51:44 -0800

> Couldn't servers give out unique URI templates?

DoH doesn't specify how the clients get the templates. At least for a
Firefox-style TRR program, what you describe can't happen because there is
a single fixed template.

-Ekr

---

From: <[email-masked]>
Date: Wed, 8 Jan 2020 16:09:30 +0000

Hi all,

I agree with Vittorio.

FWIW, slide 6 of https://datatracker.ietf.org/meeting/104/materials/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-01 shows that very few DNS providers are handling +53% of the traffic. It is fair to mention the risk to see such centralization further exacerbated. Of course, the one mentioned by Christian is to be called as well.

Cheers,
Med

De : last-call [mailto:[email-masked]] De la part de Vittorio Bertola
Envoyé : mercredi 8 janvier 2020 12:42
À : Christian Huitema; Sara Dickinson
Cc : [email-masked]; DNS Privacy Working Group
Objet : Re: [Last-Call] [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

--

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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 09 Jan 2020 13:06:05 +1100

On Wed, Jan 8, 2020, at 23:51, Eric Rescorla wrote:
> Firefox-style TRR program, what you describe can't happen because there 
> is a single fixed template.

It is true that the potential for providing individualized endpoints for tracking purposes is an exposure.  In discussing 7710bis, we identified this as a risk of DHCP specifically.  IPv6 RAs by their nature generally don't have this problem, though I'm sure a network might be built in such a way as to add that capability.  Provisioning domains do.

In the new work we are likely to undertake, this is something we'll have to consider, but I don't see it as a huge issue: if you are deferring to another entity for discovery without prior expectations about what you will get, there are many ways to get into this sort of pickle.  That is, in the context of pre-existing DNS discovery, I don't believe that this creates a new exposure to this style of attack.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Jan 2020 20:28:48 -0800

On Wed, Jan 8, 2020 at 6:06 PM Martin Thomson <[email-masked]> wrote:

> It is true that the potential for providing individualized endpoints for
> tracking purposes is an exposure.
>
...

> In the new work we are likely to undertake, this is something we'll have
> to consider, but I don't see it as a huge issue

...

> That is, in the context of pre-existing DNS discovery, I don't believe
> that this creates a new exposure to this style of attack.
>

I generally agree with this. I do think this concern is relevant in
discovered URI templates, and in assessing the value of TLS and Web PKI as
signals of trust.

thanks,
Rob

---

From: <[email-masked]>
Date: Thu, 9 Jan 2020 09:11:30 +0000

Hi Christian,

Thank you for sharing the pointer.

As I understood it, the aggregation mentioned in Pawel and Oliver's study is based on an “AS name”, not AS numbers. As you know, an organization may own multiple ASNs. Mapping the 22/57 ASes to their owner would be useful, IMO.

Cheers,
Med

De : dns-privacy [mailto:[email-masked]] De la part de Christian Huitema
Envoyé : jeudi 9 janvier 2020 09:28
À : BOUCADAIR Mohamed TGI/OLN; Vittorio Bertola; Sara Dickinson
Cc : [email-masked]; DNS Privacy Working Group
Objet : Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

On 1/8/2020 6:09 AM, [email-masked]<mailto:[email-masked]> wrote:
FWIW, slide 6 of https://datatracker.ietf.org/meeting/104/materials/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-01 shows that very few DNS providers are handling +53% of the traffic. It is fair to mention the risk to see such centralization further exacerbated. Of course, the one mentioned by Christian is to be called as well

I am not sure that I understand the methodology behind the slides that you cite, but it appears that they are measuring traffic by volume based on passive DNS data collection.

I have been working with the APNIC data, as published at https://ithi.research.icann.org/graph-m5.html. The data attempts to answer the question, how many "resolvers" handle what fraction of the user population. The first problem is "how do you identify resolvers". The classic simplification is to just count autonomous system numbers (AS), but this lumps together the resolvers managed by ISP and those managed by small businesses connecting through those ISP. The immediate problem is, "how do you count", because users and their devices sometimes send multiple copies of the same query to different resolvers, and also sometimes send a second batch of queries to a different set of resolvers if they did not get a response the first time. One way to count would be, all the resolvers needed to handle all the repetitions of the queries of a users. Let's call that the inclusive count. Another way would be, the smallest numbers of resolvers that would handle X% of the users, if all the other resolvers were out of service. Let's call that the exclusive count, which is by definition smaller than the inclusive count.

As of January 2020, the data shows that:
     * The traffic of 50% of the users is seen by resolvers in 57 AS (inclusive count). Handling that traffic would require at least 22 AS (exclusive count).
     * The traffic of 90% of the users is seen by resolvers in 570 AS (inclusive count). Handling that traffic would require at least 385 AS (exclusive count).

If we count by network prefix (/24 for IPv4, /48 for IPv6), we get:
     * The traffic of 50% of the users is seen by resolvers in 478 networks (inclusive count). Handling that traffic would require at least 143 networks (exclusive count).
     * The traffic of 90% of the users is seen by resolvers in 3403 networks (inclusive count). Handling that traffic would require at least 2150 networks (exclusive count).

Is that a form of concentration? Yes of course, but even the lowest number, 22 AS, is larger than the 8 networks mentioned as handling 53% of traffic in Pawel and Oliver's study.

And yes, it is important to monitor these trends.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 8 Jan 2020 22:28:28 -1000

On 1/8/2020 6:09 AM, [email-masked] wrote:
> FWIW, slide 6 of
> https://datatracker.ietf.org/meeting/104/materials/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-01
> shows that very few DNS providers are handling +53% of the traffic. It
> is fair to mention the risk to see such centralization further
> exacerbated. Of course, the one mentioned by Christian is to be called
> as well

I am not sure that I understand the methodology behind the slides that
you cite, but it appears that they are measuring traffic by volume based
on passive DNS data collection.

I have been working with the APNIC data, as published at
https://ithi.research.icann.org/graph-m5.html. The data attempts to
answer the question, how many "resolvers" handle what fraction of the
user population. The first problem is "how do you identify resolvers".
The classic simplification is to just count autonomous system numbers
(AS), but this lumps together the resolvers managed by ISP and those
managed by small businesses connecting through those ISP. The immediate
problem is, "how do you count", because users and their devices
sometimes send multiple copies of the same query to different resolvers,
and also sometimes send a second batch of queries to a different set of
resolvers if they did not get a response the first time. One way to
count would be, all the resolvers needed to handle all the repetitions
of the queries of a users. Let's call that the inclusive count. Another
way would be, the smallest numbers of resolvers that would handle X% of
the users, if all the other resolvers were out of service. Let's call
that the exclusive count, which is by definition smaller than the
inclusive count.

As of January 2020, the data shows that:
     * The traffic of 50% of the users is seen by resolvers in 57 AS
(inclusive count). Handling that traffic would require at least 22 AS
(exclusive count).
     * The traffic of 90% of the users is seen by resolvers in 570 AS
(inclusive count). Handling that traffic would require at least 385 AS
(exclusive count).

If we count by network prefix (/24 for IPv4, /48 for IPv6), we get:
     * The traffic of 50% of the users is seen by resolvers in 478
networks (inclusive count). Handling that traffic would require at least
143 networks (exclusive count).
     * The traffic of 90% of the users is seen by resolvers in 3403
networks (inclusive count). Handling that traffic would require at least
2150 networks (exclusive count).

Is that a form of concentration? Yes of course, but even the lowest
number, 22 AS, is larger than the 8 networks mentioned as handling 53%
of traffic in Pawel and Oliver's study.

-- Christian Huitema

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Jan 2020 16:24:59 +0100

On Tue, Jan 07, 2020 at 06:39:18PM +0000,
 Sara Dickinson <[email-masked]> wrote 

> > without regard to privacy.

May be just an informative reference to RFC 7231, specially section
9.7, would please everyone? This section seems quite comprehensive on
the issue of privacy leaks from HTTP headers.

> trade-off between functionality and privacy

Most of the time, as noted by RFC 7231 in its section 3.4.1, the
privacy leaks bring no added functionality and no optimisation.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Jan 2020 16:29:21 +0100

On Tue, Jan 07, 2020 at 06:37:38PM +0000,
 Sara Dickinson <[email-masked]> wrote 
 a message of 278 lines which said:

> There is currently no standardized discovery mechanism for DoH and
> Strict DoT servers so applications that might want to dynamically
> discover such encrypted services are not able to. At the time of
> writing, efforts to provide standardized signalling mechanisms for
> applications to also discover the services offered by local
> resolvers are in progress
> [I-D.ietf-dnsop-resolver-information]. Note that an increasing
> numbers of ISPs are deploying encrypted DNS, for example see the
> Encrypted DNS Deployment Initiative [EDDI]."

I disagree with this text, since it seems to imply that a discovery
mechanism would be a good thing. I suggest instead that any discovery
mechanism threatens the goal of DoE (DNS over Encryption) since it
could be easily used to direct users to a resolver which they disagree
with (for the same reason, DoH on Internet Access Providers is not
very interesting since, if you trust your access provider, you don't
really need DoE).

The point of DoE is to be able to have a secure link to the resolver
you decided to trust. If we are to mention discovery, I demand that
the text should be more neutral, not implying that we are missing
something.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Jan 2020 16:30:38 +0100

On Tue, Jan 07, 2020 at 02:47:02PM -0800,
 Eric Rescorla <[email-masked]> wrote 
 a message of 310 lines which said:

> public resolvers potentially decreases centralization at the margin.

Also, when we document SMTP issues, do we mention the current
centralisation in a few email providers? I don't think so. Therefore,
why doing it for the DNS?

---

From: Neil Cook <[email-masked]>
Date: Thu, 9 Jan 2020 16:26:01 +0000

> On 9 Jan 2020, at 15:30, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Well why not switch it the other way round and say that we definitely should for SMTP? It’s getting harder and harder to actually get mail delivered if you run your own mail server.

Neil

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Jan 2020 17:38:32 +0100

On Thu, Jan 09, 2020 at 04:26:01PM +0000,
 Neil Cook <[email-masked]> wrote 
 a message of 22 lines which said:

> Well why not switch it the other way round and say that we
> definitely should for SMTP?

Note there is some work here:

draft-arkko-arch-dedr-report
draft-arkko-iab-internet-consolidation

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 9 Jan 2020 18:03:15 +0000

> On 7 Jan 2020, at 22:47, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Jan 7, 2020 at 10:37 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 19 Dec 2019, at 02:09, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 

There was much follow up on this point, thank to everyone that contributed. My summary of those comments seem to be the there is a desire to include text covering the fact that centralisation is happening in many forms and has a mixed impact.  I suggest the following text 

“As with many other protocols issues around centralisation also arise with DNS. The picture is fluid with several competing factors contributing which can also vary by geographic region. These include:
* ISP outsourcing, including to third party and public resolvers
* regional market domination by one or only a few ISPs “

An increased proportion of the global DNS resolution traffic being served by only a few entities means that the privacy considerations for end users are highly dependant on the privacy policies and practices of those entities.”

I also previously proposed referencing draft-arkko-iab-internet-consolidation that Stephane mentioned, but Ekr objected.  

>> I'm not sure what the point of this text is, but it seems kind of confusing.. In particular, it's not the case that the primary reason that Firefox uses a hardcoded list is because there is no standardized discovery mechanism. 
> 
> To clarify I suggest: 
> 

The point is to describe the privacy considerations of an entirely new deployment model for DNS that didn’t exist when the original RFC was published.

> My position is you should strike this text, not attempt to rewrite it. In general, the history of trying to neutrally document controversial issues in IETF is not very encouraging, and in this case it's quite unnecesary. 

I’d argue the same as above, it is necessary to describe a new deployment model with new privacy considerations. This change is a reality for users of the Internet today so I think this document should make every effort to present an informative picture.

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 9 Jan 2020 18:03:33 +0000

> On 7 Jan 2020, at 22:51, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Jan 7, 2020 at 10:38 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 31 Dec 2019, at 14:45, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 

<snip>

> 1. That you are making predictions about what people will do and that those preductions are unsupported by evidence. That needs to go.

If you are talking about the specific text above - are you saying you don’t believe any existing implementations of encrypted DNS transports re-use sessions? If so, I can add the list of ones that do to the document. Or you believe they all use the same default configuration options?  If not what is the specific prediction you mean? 

> 2. That you are covering material that is already better covered in 8484, so why are you duplicating it?

Because this is a general overview of all DNS protocols, RFC8484 is by its nature a DoH specific treatise. 

> To repeat my question from before: this material is already in 8484, so why are you trying to write a new document that duplicates that?

As above. 

>> RFC7626 included Section 2..5.3 https://tools.ietf.org/html/rfc7626#section-2.5.3 <https://tools.ietf.org/html/rfc7626#section-2.5.3> ‘Rogue Servers’. This section is just an update of that text to improve context and remove the phrase ’rogue server’.  Since the majority of OS implementations still use these mechanisms today it seems to still be relevant. 
>> 
> Well, that's a start, but the problem is still that it's too low level. If you insist on having this section, you should lay out the implications of the situation rather than (or at least in advance of) digging into the details.

The level is detail is entirely comparible to that in the original RFC (much of the text is still the same). As I said to Martin, the section focusses on the impact on the DNS resolution path that results from the attack: diversion of traffic and traffic capture. Are there other implications you think should be included? Please suggest text. 

Sara.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 10 Jan 2020 13:45:06 +1100

On Fri, Jan 10, 2020, at 05:03, Sara Dickinson wrote:
> “As with many other protocols issues around centralisation also arise 
> with DNS. The picture is fluid with several competing factors 
> contributing which can also vary by geographic region. These include:
> An increased proportion of the global DNS resolution traffic being 
> served by only a few entities means that the privacy considerations for 
> end users are highly dependant on the privacy policies and practices of 
> those entities.”

This seems fine, but I'd have to see it in context, I think.

> I also previously proposed referencing 
> draft-arkko-iab-internet-consolidation that Stephane mentioned, but Ekr 
> objected. 

That's a poor choice for any citation at this stage.  We're a long way from having clearly articulated views on the topic, let alone having any sort of consensus.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Jan 2020 19:41:26 -0800

On Thu, Jan 9, 2020 at 10:03 AM Sara Dickinson <[email-masked]> wrote:

>>> When it comes to fingerprinting, it's important to distinguish between
>>> an ability to identify the software in use (Windows vs. Linux, Safari vs.
>>> likely to re-use sessions for multiple DNS queries to optimize performance
>>> (e.g. via DNS pipelining or HTTPS multiplexing). Default configuration
>>> options for encrypted transports could in principle fingerprint a specific
>>> client application. For example:…
>>>
>>
> 1. That you are making predictions about what people will do and that
> those preductions are unsupported by evidence. That needs to go.
>
>
> If you are talking about the specific text above - are you saying you
> don’t believe any existing implementations of encrypted DNS transports
> re-use sessions? If so, I can add the list of ones that do to the document.
> Or you believe they all use the same default configuration options?  If not
> what is the specific prediction you mean?
>

Your text says "highly likely". I'm sure that *some* implementation does,
but that doesn't make it highly likely unless you intend to say "it is
highly likely that some implementation will", which seems silly.

> nature a DoH specific treatise.

In that case you ought to just point to the text in 8484 or copy it, not
rewrite it.

>>> I would remove this section in favour of improving Section 3.5.1.4,
>>> which addresses the most pertinent question.
>>>
>>>
>>> RFC7626 included Section 2..5.3
> The level is detail is entirely comparible to that in the original RFC
> (much of the text is still the same).
>

That doesn't seem like a particularly strong argument. We're revising this
document and the question is what is good now.

As I said to Martin, the section focusses on the impact on the DNS
> resolution path that results from the attack: diversion of traffic and
> traffic capture. Are there other implications you think should be included?
> Please suggest text.
>

I would replace the entirety of this section with:

The Internet Threat model, as described in RFC 3552, assumes that the
attacker controls the network. Such an attacker can completely control any
insecure DNS resolution, both passively monitoring the queries and
responses and substituting their own responses. Even if encrypted DNS such
as DoH or DoT is used, unless the client has been configured in a secure
way with the server identity, an active attacker can impersonate the
server. This implies that opportunistic modes of DoH/DoT as well as modes
where the client learns of the DoH/DoT server via in-network mechanisms
such as DHCP are vulnerable to attack. In addition, if the client is
compromised, the attacker can replace the DNS configuration with one of its
own choosing.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Jan 2020 05:52:43 -0800

On Thu, Jan 9, 2020 at 10:03 AM Sara Dickinson <[email-masked]> wrote:

>>> “It has been pointed out that should the trend towards using large
>>> public resolvers increase, an increased centralisation of DNS resolution
>>> services will result.
>>>
>>
>> Well, it's been pointed out, but it's not at all clear that it's true,
>> due to the large amount of centralization of ISPs in certain areas, so no,
>> I don't think this document should make this claim.
>>
>>
> Yeah, my point is that I don't agree with this. Right now there is a lot
> of ISP centralization and the move of some of that traffic to public
> resolvers potentially decreases centralization at the margin. I certainly
> don't agree with citing draft-arkko, which is not at all a neutral or
> factual source, so this is just a way of incorporating by reference
> material which doesn't have consensus.
>
>
> There was much follow up on this point, thank to everyone that
> contributed. My summary of those comments seem to be the there is a desire
> to include text covering the fact that centralisation is happening in many
> forms and has a mixed impact.  I suggest the following text
>
> “As with many other protocols issues around centralisation also arise with
> DNS. The picture is fluid with several competing factors contributing which
> can also vary by geographic region. These include:
> An increased proportion of the global DNS resolution traffic being served
> by only a few entities means that the privacy considerations for end users
> are highly dependant on the privacy policies and practices of those
> entities.”
>

I understand that there are a number of people who would like to include
this material, but it isn't actually about DNS privacy in particular, nor
about DoH or DoT, which are just protocols, but about deployment models,
and so isn't really in scope here.

More generally, this document should not be trying to document or argue the
discussions that are happening about ADD.

>> confusing.. In particular, it's not the case that the primary reason that
> The point is to describe the privacy considerations of an entirely new
> deployment model for DNS that didn’t exist when the original RFC was
> published.
>

See above.
-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Jan 2020 14:50:07 +0000

On Jan 9, 2020, at 7:41 PM, Eric Rescorla <[email-masked]> wrote:
>>> RFC7626 included Section 2..5.3 https://tools.ietf.org/html/rfc7626#section-2.5.3 ‘Rogue Servers’. This section is just an update of that text to improve context and remove the phrase ’rogue server’.  Since the majority of OS implementations still use these mechanisms today it seems to still be relevant. 
>>> 
> The level is detail is entirely comparible to that in the original RFC (much of the text is still the same).
> 
> That doesn't seem like a particularly strong argument. We're revising this document and the question is what is good now.
> 
> 
> 
> As I said to Martin, the section focusses on the impact on the DNS resolution path that results from the attack: diversion of traffic and traffic capture.. Are there other implications you think should be included? Please suggest text. 
> 
> The Internet Threat model, as described in RFC 3552, assumes that the attacker controls the network. Such an attacker can completely control any insecure DNS resolution, both passively monitoring the queries and responses and substituting their own responses. Even if encrypted DNS such as DoH or DoT is used, unless the client has been configured in a secure way with the server identity, an active attacker can impersonate the server. This implies that opportunistic modes of DoH/DoT as well as modes where the client learns of the DoH/DoT server via in-network mechanisms such as DHCP are vulnerable to attack. In addition, if the client is compromised, the attacker can replace the DNS configuration with one of its own choosing.

Given that this topic is one where there is rampant confusion, I think brevity and clarity are best for this document. I believe Ekr's words cover exactly what is needed here, and agree that the rest of the section should be eliminated.

I aslo agree with earlier comments that this document referring to draft-arkko-arch-infrastructure-centralisation is a bad idea. We have no idea what that document will end up saying when published as an RFC.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Jan 2020 06:53:42 -0800

On Fri, Jan 10, 2020 at 6:50 AM Paul Hoffman <[email-masked]> wrote:

> >>> Well, as MT says, this is just the 3552 threat model.  The basic fact
> is that you need a reference to a server that is (1) securely obtained and
> (2) verifiable against the server itself. Absent that, you are subject to
> attack by the network.
> >>
> >> Suggest adding a sentence at the start of the section “[RFC3552]
> provides guidelines for describing Internet threat models. This section
> specialises the discussion to the case of DNS resolver configuration.”
> >>
> >> Well, that's a start, but the problem is still that it's too low level.
> If you insist on having this section, you should lay out the implications
> of the situation rather than (or at least in advance of) digging into the
> details.
> >
> > That doesn't seem like a particularly strong argument. We're revising
> this document and the question is what is good now.
> >
> >
> >
> traffic capture.. Are there other implications you think should be
> included? Please suggest text.
> >
> Given that this topic is one where there is rampant confusion, I think
> brevity and clarity are best for this document. I believe Ekr's words cover
> exactly what is needed here, and agree that the rest of the section should
> be eliminated.
>
> I aslo agree with earlier comments that this document referring to
> draft-arkko-arch-infrastructure-centralisation is a bad idea. We have no
> idea what that document will end up saying when published as an RFC.
>

Or whether it will be published as an RFC at all.

-Ekr

> --Paul Hoffman--
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>