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

From: "Martin Thomson" <[email-masked]>
Date: Mon, 02 Dec 2019 11:00:36 +1100

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.

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.

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?

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.

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.

Section 3.5.1.1

This section references announcements of product plans that will eventually - even by the time that this document is published - be outdated.  This is, in my view, the most controversial section of the document, and it is all based on somewhat tenuous information.

All the "at the time of writing" text in this section would need to be removed in order for me to be comfortable with the publication of this document.

Similarly, I find the following text problematic:

> If applications enable application-specific DNS settings without properly informing the user of the change (or do not provide an option for user configuration of the application's recursive resolver) there is a potential privacy issue; depending on the network context and the application default, the application might use a recursive server that provides less privacy protection than the default network-provided server without the user's full knowledge.

This text presumes a great deal about the environment into which these applications are being deployed.  It appeals to a status quo bias by examining an area of a larger change that might have negative consequences without regarding the effect in the aggregate. Moreover, it sets unrealistic expectations - "the user's full knowledge" - about what might an application might need to do in order to make these deployment decisions.  In other words, whether it was intended or not, this takes a firm stance on the current rather contentious debate.

Separately, I appreciate that some people believe that these developments signal a move toward greater centralization of the DNS service, but that too is the subject of the ongoing debate.

Maybe there is a version of this section that the IETF can publish, but not until we actually have consensus on these subjects.  I have to most strenuously object to any attempt to publish a document if this section remains.

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.

Section 3.5.1.3

The arguments here again fall under an area of active debate. The second paragraph makes the claim that in-network blocking of encrypted DNS might be done for reasons that benefit users. That relies on a number of unstated assumptions. More seriously, this particular subject is one of the most contentious parts of the current debate and it has no place in a document that purports to represent community consensus.

Either way, I think that RFC 7754 has a far better treatment of the broader topic.  This section might be better served with a reference to that.

Section 3.5.1.4

Again, this might be too close to the current debate, but I find it odd that there is no connection drawn between authentication of resolvers and choosing the resolver that receives the potentially privacy-sensitive information in queries. This choice is the single overriding issue upon which the entirety of the difficult debate depends.  Maybe there was a conscious decision to gloss over the point to avoid the controversy.  Given the significance of this point to the topic, I don't see how it can be avoided.

There's an unstated assumption throughout the document that the best defense for privacy is some form of active choice or at least informed consent on the part of end users. That too is an area where there is some contention.

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.

Section 3.5.1.5.2

I can't see anything in this section that Section 8 of RFC 8484 doesn't already say.

The text here does claim that the use of DoH rather than Do<other> is a choice to trade privacy for some other vaguely-defined property, which I might read as convenience. It is hard to read the extended treatment of this as anything other than prejudicial.  For instance, by labeling DoH as complex and requiring of detailed analysis, it implies that there are unstated intricacies that are traps for the unwary. This document is intended to demystify the privacy properties of DNS as a whole, so would it not be better to explain what the essential properties are?

The one new piece is the claim that there is fingerprinting information inherent to the use of HTTP.  While there is perhaps some merit in the argument that a narrow range of options for encoding the same semantics produce less variance, it is not clear that DNS is any more free of this sort of variance than HTTP.  Maybe HTTP has more options for the creation of side channels, but DNS isn't free of those. Aside from the Accept-Language thing - which RFC 8484 addresses - I believe that these leaks are implementation-specific and rarely an individual-specific choice, but the document strongly implies that there is a risk to individual privacy.  If that is indeed the claim, it could be made directly in more concrete terms.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Dec 2019 05:59:54 -0800

Unsurprisingly, I agree with MT here. There is a pile of material
here which is precisely the set of topics failing to achieve
consensus in ADD, so it can hardly be published as having IETF
consensus through dprive.

By example, let's focus on the following two paragraphs in
S 3.5.1.1.

   If applications enable application-specific DNS settings without
   properly informing the user of the change (or do not provide an
   option for user configuration of the application's recursive
   resolver) there is a potential privacy issue; depending on the
   network context and the application default, the application might
   use a recursive server that provides less privacy protection than the
   default network-provided server without the user's full knowledge.
   Users that are fully aware of an application specific DNS setting may
   want to actively override any default in favour of their chosen
   recursive resolver.

This is not really what one would call a neutral framing, as it fails
to acknowledge that in the general case the user has no way of knowing
what the network provided resolver is or what its policies are and
that in many cases the privacy protections offered by application
default resolvers will be superior to those offered by the
network-provided resolver. Moreover, in the current technical
environment, they have no real way of knowing they are even connecting
to the intended network-provided resolver or that their connection
to it is not under attack.

In addition, the context of this paragraph is highly misleading
coming as it does after a discussion of Firefox's plans. However,
Firefox will (1) notify users before changing their resolvers
and (2) allow the users to configure their own resolvers or disable
DoH, despite the implication in this text to the contrary.

   There are also concerns that, should the trend towards using large
   public resolvers increase, this will itself provide a privacy
   concern, due to a small number of operators having visibility of the
   majority of DNS requests globally and the potential for aggregating
   data across services about a user. Additionally the operating
   organisation of the resolver may be in a different legal jurisdiction
   than the user, which creates further privacy concerns around legal
   protections of and access to the data collected by the operator.

This too is a pile of contested statements. In particular, the legal
environment around privacy for a public resolver might be better or
worse than that for the user's network default resolver, depending on
local regulation.

-Ekr

On Sun, Dec 1, 2019 at 4:01 PM Martin Thomson <[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.
>
> > 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?
>
> 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.
>
> > 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.
>
> Section 3.5.1.1
>
> This section references announcements of product plans that will
> eventually - even by the time that this document is published - be
> outdated.  This is, in my view, the most controversial section of the
> document, and it is all based on somewhat tenuous information.
>
> All the "at the time of writing" text in this section would need to be
> removed in order for me to be comfortable with the publication of this
> document.
>
> > If applications enable application-specific DNS settings without
> properly informing the user of the change (or do not provide an option for
> user configuration of the application's recursive resolver) there is a
> potential privacy issue; depending on the network context and the
> application default, the application might use a recursive server that
> provides less privacy protection than the default network-provided server
> without the user's full knowledge.
>
> This text presumes a great deal about the environment into which these
> applications are being deployed.  It appeals to a status quo bias by
> examining an area of a larger change that might have negative consequences
> without regarding the effect in the aggregate. Moreover, it sets
> unrealistic expectations - "the user's full knowledge" - about what might
> an application might need to do in order to make these deployment
> decisions.  In other words, whether it was intended or not, this takes a
> firm stance on the current rather contentious debate.
>
> Separately, I appreciate that some people believe that these developments
> signal a move toward greater centralization of the DNS service, but that
> too is the subject of the ongoing debate.
>
> Maybe there is a version of this section that the IETF can publish, but
> not until we actually have consensus on these subjects.  I have to most
> strenuously object to any attempt to publish a document if this section
> remains.
>
> 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.
>
> The arguments here again fall under an area of active debate. The second
> paragraph makes the claim that in-network blocking of encrypted DNS might
> be done for reasons that benefit users. That relies on a number of unstated
> assumptions. More seriously, this particular subject is one of the most
> contentious parts of the current debate and it has no place in a document
> that purports to represent community consensus.
>
> Either way, I think that RFC 7754 has a far better treatment of the
> broader topic.  This section might be better served with a reference to
> that.
>
> Section 3.5.1.4
>
> Again, this might be too close to the current debate, but I find it odd
> that there is no connection drawn between authentication of resolvers and
> choosing the resolver that receives the potentially privacy-sensitive
> information in queries. This choice is the single overriding issue upon
> which the entirety of the difficult debate depends.  Maybe there was a
> conscious decision to gloss over the point to avoid the controversy.  Given
> the significance of this point to the topic, I don't see how it can be
> avoided.
>
> There's an unstated assumption throughout the document that the best
> defense for privacy is some form of active choice or at least informed
> consent on the part of end users. That too is an area where there is some
> contention.
>
> 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.
>
> Section 3.5.1.5.2
>
> The text here does claim that the use of DoH rather than Do<other> is a
> choice to trade privacy for some other vaguely-defined property, which I
> might read as convenience. It is hard to read the extended treatment of
> this as anything other than prejudicial.  For instance, by labeling DoH as
> complex and requiring of detailed analysis, it implies that there are
> unstated intricacies that are traps for the unwary. This document is
> intended to demystify the privacy properties of DNS as a whole, so would it
> not be better to explain what the essential properties are?
>
> The one new piece is the claim that there is fingerprinting information
> inherent to the use of HTTP.  While there is perhaps some merit in the
> argument that a narrow range of options for encoding the same semantics
> produce less variance, it is not clear that DNS is any more free of this
> sort of variance than HTTP.  Maybe HTTP has more options for the creation
> of side channels, but DNS isn't free of those. Aside from the
> Accept-Language thing - which RFC 8484 addresses - I believe that these
> leaks are implementation-specific and rarely an individual-specific choice,
> but the document strongly implies that there is a risk to individual
> privacy.  If that is indeed the claim, it could be made directly in more
> concrete terms.
>
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 18 Dec 2019 15:06:29 +0000

> On 2 Dec 2019, at 00:00, Martin Thomson <[email-masked]> wrote:
> 

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. 

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

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.

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

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

> 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 individu…

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:…

If libraries or applications offer user configuration of such options (e.g. [stubby]) then they could in principle help to identify a specific user.”

After a quick scan I don’t think there are other cases of word/concepts being used incorrectly but if you think there are then please do suggest text.

> Section 3.5.1.1

<snip>

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

> Either way, I think that RFC 7754 has a far better treatment of the broader topic.  This section might be better served with a reference to that.

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

> There's an unstated assumption throughout the document that the best defense for privacy is some form of active choice or at least informed consent on the part of end users. That too is an area whe…

The intent of this section is literally just a clarification of the security properties of DoH/Strict DoT vs Opportunistic DoT/Do53, nothing more. I suggest moving this text to the end of section 3.5.1.2 to put it solely in the context of attacks on configuration. 

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

> The one new piece is the claim that there is fingerprinting information inherent to the use of HTTP.  While there is perhaps some merit in the argument that a narrow range of options for encoding t…

Suggest:

OLD:
“The picture for privacy considerations and user expectations for DoH with respect to what additional data may be available to the DoH server compared to DNS over UDP, TCP or TLS is complex and requires a detailed analysis for each use case.  In particular the choice of HTTPS functionality vs privacy is specifically made an implementation choice in DoH and users may well have differing privacy expectations depending on the DoH use case and implementation.”

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

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 18 Dec 2019 15:06:39 +0000

> I am opposed to the IETF publishing this document in its current form.

Attempting to address both Martin and Ekr’s comments on section 3.5.1.1. here...

> Maybe there is a version of this section that the IETF can publish, but not until we actually have consensus on these subjects.  I have to most strenuously object to any attempt to publish a docume…

Suggest replacing the last 4 paragraphs of this section with the following text. 

“It has been pointed out that should the trend towards using large public resolvers increase, an increased centralisation of DNS resolution services will result. 

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

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

Sara.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Dec 2019 18:09:23 -0800

On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson <[email-masked]> wrote:

> > 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.
> >
> > Separately, I appreciate that some people believe that these
> developments signal a move toward greater centralization of the DNS
> service, but that too is the subject of the ongoing debate.
> >

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.

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.

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].”
>
> Sara.
>
>

---

From: Rob Sayre <[email-masked]>
Date: Wed, 18 Dec 2019 20:05:42 -0800

> don't think this document should make this claim.

Agree.

> Firefox uses a hardcoded list is because there is no standardized discovery

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?

>> highly desirable that applications
Is it "highly desirable", though?

> * communicate clearly the change in default to users
Not clearly true, since the status quo is often not clearly communicated.

> * provide configuration options to change the default
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.

> * provide configuration options to always use the network provided resolver
"network provided resolver" is not well-defined.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 31 Dec 2019 06:45:20 -0800

On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson <[email-masked]> 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.
>
>
> Section 2
>
> 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.
>

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"

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

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

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.

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"

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

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.

-Ekr

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 31 Dec 2019 17:33:27 +0100 (CET)

Il 31/12/2019 15:45 Eric Rescorla <[email-masked]> ha scritto:

On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson <
[email-masked]> wrote:

Suggest:

OLD:

NEW:

I don't generally think that documents like this ought to predict how implementers will behave, so I would remove this text entirely.

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.

As I understood it, the purpose of this document is to map possible DNS-related privacy issues, and not necessarily to address them with recommendations (and in that case you are right that there might be a privacy vs performance tradeoff). So the starting point here was to state that a privacy risk exists, even if we are not ready to make recommendations (which may come in the future in a "7626ter" document) or even to assess whether the risk is big enough to even need recommendations (which, I agree, will greatly depend on what implementers will do).

On the other hand, I think there is agreement (is there?) that encrypted DNS protocols introduce specific tracking opportunities deriving from how they open and reuse connections and from other features of the encrypted transport mechanism, so it would be weird to omit this risk from the analysis.

--

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 31 Dec 2019 10:45:02 -0800

On Tue, Dec 31, 2019 at 8:33 AM Vittorio Bertola <
[email-masked]> wrote:

> On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson < [email-masked]> wrote:
>
>
> Suggest:
>
> OLD:
> As I understood it, the purpose of this document is to map possible
> DNS-related privacy issues, and not necessarily to address them with
> recommendations (and in that case you are right that there might be a
> privacy vs performance tradeoff). So the starting point here was to state
> that a privacy risk exists, even if we are not ready to make
> recommendations (which may come in the future in a "7626ter" document) or
> even to assess whether the risk is big enough to even need recommendations
> (which, I agree, will greatly depend on what implementers will do).
>
> On the other hand, I think there is agreement (is there?) that encrypted
> DNS protocols introduce specific tracking opportunities deriving from how
> they open and reuse connections and from other features of the encrypted
> transport mechanism, so it would be weird to omit this risk from the
> analysis.
>

This analysis is already covered extensively in RFC 8484, Section 2. Rather
than trying to rephrase it here, I would recommend linking to that.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 31 Dec 2019 14:35:55 -0800

On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson <[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.

thanks,
Rob