Subject: [Doh] some privacy ponderings wrt HTTPs and plain DNS

From: bert hubert <[email-masked]>
Date: Mon, 18 Jun 2018 13:21:16 +0200

Hi everyone,

I'm happy with the progress in -11 and hope we can see this in standardized
production soon!

One thing I would like to note though, but I'm not sure if it has a place in
the draft: the differential privacy aspects of DNS versus DNS over HTTPS.

DNS is encoded so tightly that there is almost no variation in queries
coming from stub resolvers.  Your esp8266, fridge, microwave and iPhone X
all send out bit for bit identical queries, and this is a wonderful thing.

HTTPs however can be highly identifiable.  Over the course of a week, over
4000 different agent strings visited https://ds9a.nl/ and
https://powerdns.org/, for example (and this is excluding bots). This allows
DoH servers to differentiate different devices in a household easily, since
most of them will have a unique string.

In addition, HTTP can carry further identifying headers like accepted
languages, HSTS settings (perhaps) or even cookies. 

It has also been observed that TLS session resumption data provides a way to
semi-persistently track individual TLS originators (but I don't know for how
long).

With all this, there is the clear risk that DoH as a privacy feature will at
first succeed in providing DNS operators with a more detailed insight into
per-device browsing habits, something they may not be shy to monetize.

I have discussed this on Twitter with various HTTP users and they opined
that since they were supplying these headers already anyhow the privacy
impact is minimal. After some discussion & dumping of headers, I think they
agreed it is not necessary to send out a user's language preferences with
DNS request, nor the CPU, or the operating system or the exact browser
version.

As noted, I don't know if this has a place in the draft, but I'd recommend
DoH clients to:

* Set their Agent to 'DoH client', no matter what browser/library
* Do not pass non-essential HTTP headers (like language)
* Do not allow the DoH server to set cookies
* Ponder TLS sessions resumption data settings
* Think about all other ways in which HTTP can be tracked (HSTS?)

Thoughts?

	Bert

---

From: nusenu <[email-masked]>
Date: Mon, 18 Jun 2018 12:49:00 +0000

> * Think about all other ways in which HTTP can be tracked (HSTS?)

Thanks for this, I find it rather important to avoid introducing new data 
collection opportunities (at the resolver) that haven't been there on plain DNS 
and support your recommendations to minimize data exposure.

Ideally all DoH clients look the same from the DoH server perspective.
This this will never be completely the case but we should try to minimize
the DoH client fingerprintability.

I hope the minimization of the DoH client fingerprint becomes a mandatory part
in the document.

This is also in-line with the spirit of RFC6973
Privacy Considerations for Internet Protocols

specifically section 6.1 and 7.1
https://tools.ietf.org/html/rfc6973#section-6.1
https://tools.ietf.org/html/rfc6973#section-7.1

"What identifiers could be omitted or be made less
identifying while still fulfilling the protocol's goals?"
is always a good question to ask.

kind regards,
nusenu

-- 
https://twitter.com/nusenu_

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 18 Jun 2018 14:47:25 +0100

> On 18 Jun 2018, at 13:49, nusenu <[email-masked]> wrote:
> 
> Signed PGP part

+1 on this. DNSOP and DPRIVE have both acknowledged that client identifiers in DNS messages directly compromise user privacy and have attempted to minimise or mitigate their use (for example see RFC7626, RFC7871 or draft-tale-dnsop-edns0-clientid). The DoH WG should be doing the same (or at least no less).

> is always a good question to ask.

And given that the charter says 
“The working group will analyze the security and privacy issues that
could arise from accessing DNS over HTTPS. “

it suddenly strikes me that this draft doesn’t contain a Privacy Considerations section. I would suggest that one is added to address this issue and offer to help with text on that. 

On a technical note do we have 2 use cases to deal with?
- one where dedicated connections are used for DoH (i.e. where only DoH requests are made)
- one where DoH requests are intermingled on the same connection with existing traffic (which will most likely include headers already identifying the client)

Sara.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 18 Jun 2018 10:25:31 -0400

In the interest of moving forward, given that we've completed wglc a couple
of times, I'm going to incorporate this as a ietf last-call comment and
include text as part of that cycle.. there is surely something useful that
can be written

in the big picture, this is something that I would like to see handled by
BCP56-bis, but doesn't seem to be addressed at all there. That's probably a
good comment for that draft.

some more specific things to consider when writing text that come to my
mind:
* content negotiation is something doh clients will want to do as a normal
part of http, and most of this information is related.. e.g. accept-language
* many headers leak state but are tied to http features that clients might
choose to participate in anyhow (e.g. cache revalidation headers)
* versioning information helps prevent bugs from becoming defacto features
forever.
* authentication is a normal thing to do
* there are lots of headers that we don't know about - and that's ok. Let's
provide advice rather than be a whitelisting firewall.
* entities other than DoH clients and DoH servers participate in a DoH
exchange (proxies, lb, etc) so be aware that there is an asymmetry between
send and recv in this spec. (i.e. you can say a DoH client cannot send Foo,
but you cannot say that a DoH server receiving Foo is a protocol error
because generic HTTP in between might add it.)

wrt Sara's specific comment about the differences between connection
contexts - that's not a difference the core semantic layer of HTTP
presents. from that pov HTTP is stateless. its often not something the
client interface exposes very well, and is certainly not necessarily an end
to end property. So any text in that neighborhood probably needs to be
along the lines of fyi.

So I think DoH will need to say something fairly generic along the lines of
"think about the meta data tradeoffs and explicitly enable features you
need".

On Mon, Jun 18, 2018 at 9:47 AM, Sara Dickinson <[email-masked]> wrote:

> +1 on this. DNSOP and DPRIVE have both acknowledged that client
> identifiers in DNS messages directly compromise user privacy and have
> attempted to minimise or mitigate their use (for example see RFC7626,
> RFC7871 or draft-tale-dnsop-edns0-clientid). The DoH WG should be doing
> the same (or at least no less).
>
>
> it suddenly strikes me that this draft doesn’t contain a Privacy
> Considerations section. I would suggest that one is added to address this
> issue and offer to help with text on that.
>
> - one where DoH requests are intermingled on the same connection with
> existing traffic (which will most likely include headers already
> identifying the client)
>
> Sara.
>
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
>

---

From: nusenu <[email-masked]>
Date: Mon, 18 Jun 2018 15:31:00 +0000

> could arise from accessing DNS over HTTPS. “

Thanks for citing this, it nails the problem pretty much.
Privacy problems arising from the specific combination of DNS over HTTPS
and their mitigation should be in the scope of the document.

> it suddenly strikes me that this draft doesn’t contain a Privacy Considerations section. I would suggest that one is added to address this issue and offer to help with text on that. 

+1 for a Privacy Consideration section (in fact I was looking for it already).

Given the discussion in this thread:
https://twitter.com/PowerDNS_Bert/status/1008081220603916289

I would also find it helpful to define the threat model (i.e. DoH server is not
necessarily ultimately trusted and data minimization still makes sense even 
if you are trusting the DoH server to learn your DNS queries - or especially because
you give it your queries you don't want to allow him to identify/track DoH clients or link all the
queries to a single DoH client). Queries alone are also potentially enough to identify/link someone.

> - one where DoH requests are intermingled on the same connection with existing traffic (which will most likely include headers already identifying the client)

I was thinking about the same problem that would arise from a single connection being used
for DoH server (no cookies) and for "normal" web content (with cookies) requests.
Depending on how a DoH client implement a 'no cookies for DoH servers' protection [1]
it might allow a DoH server to link a cookie to a DoH client if cookie and non-cookie requests
are multiplexed over the same connection.

[1] https://twitter.com/mcmanusducksong/status/1008374832923279360

btw: Is this a typo in the charter?

"This will enable the domain name system to
function over certain paths where existing DNS methods (UDP, TLS [RFC 7857], ..."

RFC 7857 vs. RFC 7858?

---

From: Star Brilliant <[email-masked]>
Date: Mon, 18 Jun 2018 16:00:45 +0000

Hi,

I don't think we should not make it default, because most people need these things. We shouldn't include these in the standard either, since it is purely implementation dependent.

You may want to disable these features for your own preference. And you may develop, use, or recommend a client software that has options to disable these features.

Let me describe them item by item (sorry it's long):

*****

> * Set their Agent to 'DoH client', no matter what browser/library

Usually we need to include the software versions, mainly because older software may contain bugs, we need to take special care of them. (e.g. Some old clients may use the obsolete application/dns-udpwireformat or message/dns MIME types, so we need to be compatible.)

Also, we need to give warning or stop service for certain clients that are known to serious security flaws. Otherwise, the users may not be aware that they need to install security patches.

Third, it is useful if we can give separate error messages for human (browser) and standalone clients. Users may accidentally click into a DoH URL without any intention to do DNS query. Do we need to give them a 400 error, or a 302 redirect to a human-readable help page?

*****

> * Do not pass non-essential HTTP headers (like language)

For browsers, we usually cannot control it through XHR API.

For standalone clients, nobody would send extra headers since that requires extra code.

Since we cannot do anything to change it, I think it is useless to talk about it.

*****

> * Do not allow the DoH server to set cookies

Do you know RFC7873? Yes, there is already a Cookie system for traditional DNS protocol. And many public DNS services are already using it to protect against DDoS attack.

Additionally, since DoH protocol usually relies on Keep-Alive connections (otherwise it would be painfully slow), a single connection usually correspond to a single user or a single group of users, isn't it?

Similar to RFC7873 Cookie, HTTP Cookie also serves as a tool to defend servers from DDoS attacks, and is already widely adapted by many leading CDN providers.

My suggestions is to give the user an option to disable Cookies, or limit Cookies to a very short lifetime (e.g. 2 minutes).

So I think it is better to provide an option instead of making the choice for the user. A "disable Cookie" option is already implemented in my implementation of DoH protocol suite (check below for the software).

*****

> * Ponder TLS sessions resumption data settings

I am not familiar with this protocol. I guess disabling it will make connections much slower? (200x CPU time according to CloudFlare blog.)

Anyhow either enabling or disabling it does not affect security, because again, DoH usually relies on Keep-Alive connections and the user's IP can be tracked.

Since this feature can be turned on or off solely on the client side, you can just use a client that disables this feature, without relying anything from the server.

*****

> * Think about all other ways in which HTTP can be tracked (HSTS?)

I don't think HSTS can be a problem if we always copy-and-paste DoH URLs.

You may run a non-standard DoH server through plaintext HTTP protocol for debugging or other purposes. But we strongly disrecommends using any DoH URL that does not starts with "https:".

*****

Extra A: Keep-Alive and Tor

I just talked about Keep-Alive. Since DoH runs over HTTP/2, Keep-Alive is normally enabled. If you are worried about it, you can run a non-standard DoH client with HTTP/1.0 over HTTPS. Please be warned that this is non-standard, and painfully slow, and burdens the server that may cause your IP to be banned by them.

If you use DoH through Tor, I recommend you try CloudFlare's DoH hidden service. It's fast, secure, and private. (Disclaimer: This is purely a personal recommendation and is not related with any promotional activities)

*****

Extra B: ECS and IP tracking

I consider RFC7871 (EDNS Client Subnet) an important feature with DoH. This protocol is used by many traditional servers to provide geolocationally-near results. Servers without ECS rely on Anycast.

Anycast does not solve all problems, especially for some countries where competing ISPs deprioritize inter-ISP traffic. (e.g. China Mobile -> Hong Kong Mobile has lower ping than China Mobile -> China Telecom)

For DoH, which is TCP traffic, Anycast becomes much more difficult so DoH service providers may want to deploy ECS on their servers. A serious issue emerges since ECS submits part of the client's IP address (/24 or /48) to the authoritative DNS server. Some users like this feature, while others hate it for privacy reasons.

A positive scenario of this feature is one of my user from China deployed a DoH server outside China, submitting a Chinese IP address through ECS protocol so he can enjoy an MITM-less DNS life but can also watch videos without lag from CDN servers located in the same ISP with him. (DNS MITM is deployed country-wide inside China.)

I thought about this feature seriously and decided to provide an option for the user in my own implementation. Good news is that, if disabled, I will even send a flag telling upstreams to turn off any already enabled-by-default ECS features.

*****

Conclusions:

I agree that some users need the features Bert Hubert have just enumerated. But for most of the time, these features would decrease service satisfactory for the users.

Users would not prefer DoH if DoH is much slower, or is not DDoS-resistant, or is not GeoDNS-compliant, or is simply not secure enough (privacy != security).

So let's make them options. The world is colorful if DoH implementations are different from each other: some care about privacy and some do good on lightning speed.

*****

My implementation:

I took my own DoH implementation as an example of providing abundant options for the sake of users' privacy.

If you want to check it and give suggestions to it, please refer to https://github.com/m13253/dns-over-https .

-- 
Best regards,
StarBrilliant

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 18 Jun 2018 17:36:11 +0100

> On 18 Jun 2018, at 15:25, Patrick McManus <[email-masked]> wrote:
> 
> In the interest of moving forward, given that we've completed wglc a couple of times, I'm going to incorporate this as a ietf last-call comment and include text as part of that cycle.. there is surely something useful that can be written

Erm, did you mean IESG not IETF LC?

> 
> in the big picture, this is something that I would like to see handled by BCP56-bis, but doesn't seem to be addressed at all there. That's probably a good comment for that draft.
> 
> some more specific things to consider when writing text that come to my mind:
> * content negotiation is something doh clients will want to do as a normal part of http, and most of this information is related.. e.g. accept-language
> * many headers leak state but are tied to http features that clients might choose to participate in anyhow (e.g. cache revalidation headers)
> * versioning information helps prevent bugs from becoming defacto features forever.
> * there are lots of headers that we don't know about - and that's ok. Let's provide advice rather than be a whitelisting firewall.
> * entities other than DoH clients and DoH servers participate in a DoH exchange (proxies, lb, etc) so be aware that there is an asymmetry between send and recv in this spec. (i.e. you can say a DoH client cannot send Foo, but you cannot say that a DoH server receiving Foo is a protocol error because generic HTTP in between might add it.)

Thanks for the list… it certainly provides context to understand that HTTP as a substrate brings a significant overhead (as well as all the benefits of such bells and whistles).

So I think what I am hearing here is that the use of DoH effectively comes at the price of accepting that additional overhead and all its potential privacy/tracking issues because in practice it is rather impossible and/or impractical to have ‘bare’ DoH that transmits only as much information about the user as, for example, typical DNS-over-TLS?

I see the trade-offs here, I just want to make sure I understood correctly….

> 
> wrt Sara's specific comment about the differences between connection contexts - that's not a difference the core semantic layer of HTTP presents. from that pov HTTP is stateless. its often not something the client interface exposes very well, and is certainly not necessarily an end to end property. So any text in that neighborhood probably needs to be along the lines of fyi.
> 
> So I think DoH will need to say something fairly generic along the lines of "think about the meta data tradeoffs and explicitly enable features you need”.

So from a privacy point of view there is no clear way at the protocol level to separate DoH traffic from other HTTPS traffic? In other words any considerations of data minimisation would have to be framed in that context (i.e. DoH traffic can’t necessarily be isolated)?

Sara. 

> 
> 
> On Mon, Jun 18, 2018 at 9:47 AM, Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 18 Jun 2018, at 13:49, nusenu <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Signed PGP part
>> https://tools.ietf.org/html/rfc6973#section-6.1 <https://tools.ietf.org/html/rfc6973#section-6..1>
>> https://tools.ietf.org/html/rfc6973#section-7.1 <https://tools.ietf.org/html/rfc6973#section-7.1>
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/doh <https://www.ietf.org/mailman/listinfo/doh>
> 
>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 18 Jun 2018 13:58:03 -0400

On Mon, Jun 18, 2018 at 12:36 PM Sara Dickinson <[email-masked]> wrote:

> In the interest of moving forward, given that we've completed wglc a
> couple of times, I'm going to incorporate this as a ietf last-call comment
> and include text as part of that cycle.. there is surely something useful
> that can be written
>
>
> * there are lots of headers that we don't know about - and that's ok.
> Let's provide advice rather than be a whitelisting firewall.
> Thanks for the list… it certainly provides context to understand that HTTP
> as a substrate brings a significant overhead (as well as all the benefits
> of such bells and whistles).
>
> So I think what I am hearing here is that the use of DoH effectively comes
> at the price of accepting that additional overhead and all its potential
> privacy/tracking issues because in practice it is rather impossible and/or
> impractical to have ‘bare’ DoH that transmits only as much information
> about the user as, for example, typical DNS-over-TLS?
>
> So I think DoH will need to say something fairly generic along the lines
> of "think about the meta data tradeoffs and explicitly enable features you
> need”.
>
>
> So from a privacy point of view there is no clear way at the protocol
> level to separate DoH traffic from other HTTPS traffic? In other words any
> considerations of data minimisation would have to be framed in that context
> (i.e. DoH traffic can’t necessarily be isolated)?
>

Depending on the client architecture, isolation may or may not be
feasible.  Depending on the use case, isolation may or may not increase
privacy.  For example, multiplexing DOH traffic into a single HTTP session
with non-DOH HTTP traffic might provide a stronger defense against length
and timing analysis.

There is very little that we can recommend categorically across the wide
variety of potential uses for DOH, but I'm glad the authors are planning to
add some text on this topic to help implementers avoid accidental
disclosures.

>> <https://tools.ietf.org/html/rfc6973#section-6..1>

---

From: Patrick McManus <[email-masked]>
Date: Mon, 18 Jun 2018 14:04:01 -0400

> Erm, did you mean IESG not IETF LC?
I think we're talking about the same thing. After the WG shepherd submits
the doc to the iesg, they will issue a ietf-wide last call. We can make the
additions we're talking about here as part of those inevitable updates.

> about the user as, for example, typical DNS-over-TLS?

more impractical than impossible - at the extreme, you would be building a
mere tunnel rather than really building an HTTP application. But its
totally appropriate to highlight that there are various tradeoffs that can
be made by implementations. e.g. firefox will not accept server cookies
right now on DoH transactions nor will it allow authentication. But, in a
different circumstance, a DoH client might want to use cookie-drive auth
totally reasonably (imagine a subscription based DoH service) - so its not
something the protocol should prohibit but we can mention.

> (i.e. DoH traffic can’t necessarily be isolated)?
I think you're right - especially when you consider the "HTTP chain" is
more than just the originating client. Also note that mixing has very good
sides for privacy as well - indeed while there are pros and cons I think
mixing is a net good. (it deters traffic analysis, it minimizes handshakes
and sni, etc.. while separation tends to be more easily defeated by IP
analysis or behavioral correlation by the terminating server)

---

From: Benno Overeinder <[email-masked]>
Date: Mon, 18 Jun 2018 23:02:11 +0200

On 18/06/2018 20:04, Patrick McManus wrote:
> 
> 
> On Mon, Jun 18, 2018 at 12:36 PM, Sara Dickinson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Thanks for the list… it certainly provides context to understand
>     that HTTP as a substrate brings a significant overhead (as well as
>     all the benefits of such bells and whistles).
> 
>     So I think what I am hearing here is that the use of DoH effectively
>     comes at the price of accepting that additional overhead and all its
>     potential privacy/tracking issues because in practice it is rather
>     impossible and/or impractical to have ‘bare’ DoH that transmits only
>     as much information about the user as, for example, typical
>     DNS-over-TLS?
> 
> 
> 
> more impractical than impossible - at the extreme, you would be building
> a mere tunnel rather than really building an HTTP application. But its
> totally appropriate to highlight that there are various tradeoffs that
> can be made by implementations. e.g. firefox will not accept server
> cookies right now on DoH transactions nor will it allow authentication.
> But, in a different circumstance, a DoH client might want to use
> cookie-drive auth totally reasonably (imagine a subscription based DoH
> service) - so its not something the protocol should prohibit but we can
> mention..

Thank you, I would certainly appreciate some wording about the
consideration (or trade-off) between the various implementation
decisions.  I understand it is difficult to cover all variants, but as
you mention above, one can describe the extremes and how these relate
to, for example, privacy considerations used in the DPRIVE WG RFCs and
Internet drafts.

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Jun 2018 21:39:51 +0000

On Jun 18, 2018, at 2:02 PM, Benno Overeinder <[email-masked]> wrote:
> 
> I understand it is difficult to cover all variants, but as

Note that what is being asked for here are a set of privacy considerations that go beyond what was considered in the DPRIVE WG for DNS-over-TLS, RFC 7858. The type of user profiling that triggered this thread also applies to things like TLS extensions, ordering of messages, TCP behavior in the setup, and so on, but those considerations were not listed in RFC 7858.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Jun 2018 22:43:59 +0100

On 18/06/18 22:39, Paul Hoffman wrote:
>> I understand it is difficult to cover all variants, but as you
>> mention above, one can describe the extremes and how these relate 
>> to, for example, privacy considerations used in the DPRIVE WG RFCs
>> and Internet drafts.
> 
> Note that what is being asked for here are a set of privacy
> considerations that go beyond what was considered in the DPRIVE WG
> for DNS-over-TLS, RFC 7858. The type of user profiling that triggered
> this thread also applies to things like TLS extensions, ordering of
> messages, TCP behavior in the setup, and so on, but those
> considerations were not listed in RFC 7858.

FWIW, I support the WG doing as much on this as can be done.
That that requires additional effort is ok, even if that slows
things down a little IMO - I think that's the correct reaction
to what I think is new information - new in that we (or me at
least;-) didn't consider the delta between DNS/TLS and DNS/HTTPs
in these terms before.

Cheers,
S.

> 
> --Paul Hoffman _______________________________________________ Doh
> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/doh
>

---

From: nusenu <[email-masked]>
Date: Mon, 18 Jun 2018 23:29:00 +0000

> I don't think we should not make it default, because most people need
> these things. We shouldn't include these in the standard either,
> since it is purely implementation dependent.
> 
> You may want to disable these features for your own preference. And
> you may develop, use, or recommend a client software that has options
> to disable these features.

Defining the user-agent in the specification is a direct possibility 
to avoid additional metadata/identifier that is not there in current DNS
and _not_ needed to fulfill the protocol goals. 

By saying "ok those that want to have privacy can set the agent to 'DoH client'"
will reduce the anonymity set and therefore the privacy of users.
(In fact if you are the only one setting it to 'DoH client' it is worse than 
doing nothing.)

DNS did pretty well without an user agent until now, lets ot add one
now in a protocol that aims to enhance privacy.

If MUST is not feasible, lets have at least a SHOULD for a static user agent string
to encourage a privacy-by-default setting (opt-out, not opt-in).

Specifying the user agent string in the draft will increase the likelihood that multiple
implementations will look the same at *some* level for the DoH server,
which increases the anonymity set and therefore the user's privacy.

> Usually we need to include the software versions, mainly because
> older software may contain bugs, we need to take special care of
> them. 

I agree that data like user-agent strings is helpful for debugging
and to implement server-side workarounds for client-side bugs or error handling but 
the privacy of users - in a protocol that's primary goal is to provide 
privacy for end users - should be more important than ease-of-debugging
for us operators of DoH servers.

> For standalone clients, nobody would send extra headers since that

I'd suggest to add the recommendation to send minimal headers 
even if it might be obvious to some.

> Do you know RFC7873? Yes, there is already a Cookie system for
> traditional DNS protocol. And many public DNS services are already
> using it to protect against DDoS attack.
> 
> Additionally, since DoH protocol usually relies on Keep-Alive
> connections (otherwise it would be painfully slow), a single
> connection usually correspond to a single user or a single group of
> users, isn't it?

That will not be the case for all DoH clients.

I guess there is no expectation of unlinkability within multiple
DNS queries going over a single TCP connection. The concern
with cookies is more about linking multiple TCP connections
based on the cookie.

> I am not familiar with this protocol. I guess disabling it will make
> connections much slower? (200x CPU time according to CloudFlare
> blog.)
> 
> Anyhow either enabling or disabling it does not affect security,
> because again, DoH usually relies on Keep-Alive connections and the
> user's IP can be tracked.

Not all DoH clients will use a single connection to maintain unlinkability properties
between some queries.
The IP address might not be a meaningful identifier if you do DoH over Tor
or it might not be available at all for DoH servers accessed via onion services.
https://blog.cloudflare.com/welcome-hidden-resolver/

> I just talked about Keep-Alive. Since DoH runs over HTTP/2,
> Keep-Alive is normally enabled. If you are worried about it, you can
> run a non-standard DoH client with HTTP/1.0 over HTTPS. Please be
> warned that this is non-standard

The current draft RECOMMENDS HTTP/2 but does not require it, or
did I overlook the HTTP/2 requirement elsewhere?

"HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use
with DoH"

- -- 
https://mastodon.social/@nusenu
twitter: @nusenu_

---

From: nusenu <[email-masked]>
Date: Tue, 19 Jun 2018 00:34:00 +0000

>> considerations were not listed in RFC 7858.

Maybe lets start with the easier things like user-agent
and then work towards harder to tackle identifiers?

> least;-) didn't consider the delta between DNS/TLS and DNS/HTTPs

Thanks! The prioritization of strong privacy properties over
a faster completion of the specification process is much appreciated.

---

From: Star Brilliant <[email-masked]>
Date: Tue, 19 Jun 2018 04:45:14 +0000

>"HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use

Sorry I remembered the old text. (It was once a "MUST" in the past.)

But what are you expecting with a DoH protocol running over HTTP/1.0?
I mean, it is nothing better than a DNS-over-TLS-without-session-resumption.

> for us operators of DoH servers.

If you think User-Agent can be a problem, then you shouldn't use TLS either.
When you look at the Client Hello packet, you will find different browsers have different things in it. Even different versions of a same browser are not identical.
As far as I know, Chinese government use this technique to block certain TLS protocols, including Tor and OpenVPN.
This is far far far more "plaintext fingerprintable" than a User-Agent.

Additionally, detecting a server or a client's software version is actually very easy.
I knew there is a certain bug that can't handle ECS headers well in a certain version of miekg/dns Go library.
I constructed a packet containing this certain header and sent it to CloudFlare. They crashed and returned nothing.
Now I knew CloudFlare's DNS implementation was written in Go. And they even were even using the old version! (I'm not sure about now.)
The client side is the same, as far as I know, miekg/dns has some difficulty processing some Rcode values.

To conclude: Hiding User-Agent does nothing to protect privacy. Oppositely, hiding User-Agent reduces user's security and service availability.

> with cookies is more about linking multiple TCP connections

Let me explain my worries: I run a public DoH service. Now it is healthy because few people are using. I am afraid it may receive DDoS attack in the future, so I planned to use Cookie challenge (with 2 minutes lifetime) whenever I got attacked.
What should I do now if I am not allowed to use Cookies?

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 19 Jun 2018 16:03:54 +0100

> On 18 Jun 2018, at 19:04, Patrick McManus <[email-masked]> wrote:
>> On 18 Jun 2018, at 15:25, Patrick McManus <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> I think we're talking about the same thing. After the WG shepherd submits the doc to the iesg, they will issue a ietf-wide last call. We can make the additions we're talking about here as part of those inevitable updates.

Ok, but my point was going to be that… doesn’t the decision on when this issue gets dealt lie with the WG and chairs, not the document authors?

<snip>

> more impractical than impossible - at the extreme, you would be building a mere tunnel rather than really building an HTTP application. But its totally appropriate to highlight that there are various tradeoffs that can be made by implementations. e.g. firefox will not accept server cookies right now on DoH transactions nor will it allow authentication. But, in a different circumstance, a DoH client might want to use cookie-drive auth totally reasonably (imagine a subscription based DoH service) - so its not something the protocol should prohibit but we can mention..

OK - so essentially in this specification of DoH the DoH protocol inherits the privacy qualities of HTTPS, it is not attempting to maintain or impose those of existing DNS over UDP/TCP/TLS wrt user identifiability.  

Given that, here is some text as a proposed starting point for a Privacy Considerations section - it is intended mainly as an ‘analysis’ of the current situation and I fully expect the recommendations at the end to be the subject of debate :-)

Privacy Considerations
----------------------------

When considering how the use of DoH affects user privacy (for example, compared with DNS over UDP, TCP or TLS) it is helpful to follow the analysis in both RFC7626 (DNS Privacy Considerations) and RFC6973 (Privacy Considerations for Internet Protocols). 

With reference to Section 2.4 of RFC7626 “On the wire”:

The privacy expectations of a user of DoH are relatively straightforward:

+ DoH encrypts DNS traffic and requires authentication of the server. This clearly mitigates passive surveillance and active attacks attempting to divert DNS traffic to rogue servers.
+ The use of port 443 by default and the ability to intermingle DNS traffic with HTTP traffic on the same connection can preventing on-path devices from interfering with DNS operations and make DNS traffic analysis more difficult.

With reference to Section 2.5 of RFC7626 “In the Servers”:

HTTP and DNS are very different protocols. There exists a natural tension between 
* the wide practice in HTTP to use various headers to optimise HTTP connections, functionality and behaviour (which can facilitate user identification and tracking)
* and the fact that currently DNS is very tightly encoded and contains no standardized user identifiers (since they are acknowledged as compromising user privacy). 

DNS-over-TLS, for example, would normally contain no client identifiers in the DNS messages and a resolver would see only a stream of DNS queries originating from a client IP address. Whereas if DoH clients commonly include several headers in a DNS message (e.g. user-agent and accept-language) this could lead to the resolver being able to identify the source of individual DNS requests not only to a specific end user device but to a specific application. 

Additionally, depending on the client architecture, isolation of DNS queries from other HTTP traffic may or may not be feasible or desirable.  Depending on the use case, isolation of DNS queries from other HTTP traffic may or may not increase privacy. 

The picture for privacy considerations and user expectations here is complex and will require a more detailed analysis for each particular use case. At the extremes, there may be use cases that attempt to achieve parity with DNS-over-TLS from a privacy perspective at the cost of using no identifiable headers, there might be others that provide feature rich data flows where the low-level origin of the DNS query is easily identifiable. 

As guidance, implementors should consider the following:

1.  RFC6973 discusses data minimisation in detail and says:

“Data minimization mitigates the following threats: surveillance, stored data compromise, correlation, identification, secondary use, and disclosure."

2. Implementors should evaluate what identifiers could be omitted or be made less identifying while still fulfilling the protocol's goals. 

  a. Specifically, implementors SHOULD not use non-essential HTTP headers in DoH messages and SHOULD set the user agent string to ‘DoH client’.

  b. Implementations SHOULD only accept cookies or allow client authentication when it is required to fulfil the protocols goals (e.g. a subscription service with user opt-in).

Sara.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 19 Jun 2018 11:28:07 -0400

On Tue, Jun 19, 2018 at 11:03 AM, Sara Dickinson <[email-masked]> wrote:

>
>
> Ok, but my point was going to be that… doesn’t the decision on when this
> issue gets dealt lie with the WG and chairs, not the document authors?
>

Of course! But Ben already announced we were moving to the next phase on
May 29th. So I'm just trying to communicate how we get the new issue
integrated given where we're at.

OK - so essentially in this specification of DoH the DoH protocol inherits
> the privacy qualities of HTTPS, it is not attempting to maintain or impose
> those of existing DNS over UDP/TCP/TLS wrt user identifiability.
>

I broadly agree.

>
> Given that, here is some text as a proposed starting point for a Privacy
> Considerations section - it is intended mainly as an ‘analysis’ of the
> current situation and I fully expect the recommendations at the end to be
> the subject of debate :-)
>
>
thanks for text! That's helpful...

---

From: Erik Nygren <[email-masked]>
Date: Tue, 19 Jun 2018 11:49:03 -0400

On Tue, Jun 19, 2018 at 11:03 AM, Sara Dickinson <[email-masked]> wrote:
>
>
> 2. Implementors should evaluate what identifiers could be omitted or be
> made less identifying while still fulfilling the protocol's goals.
>
>   a. Specifically, implementors SHOULD not use non-essential HTTP headers
> in DoH messages and SHOULD set the user agent string to ‘DoH client’.
>
>   b. Implementations SHOULD only accept cookies or allow client
> authentication when it is required to fulfil the protocols goals (e.g. a
> subscription service with user opt-in).
>

I'd think we'd want to avoid normative language in the Privacy
Considerations?
We should be careful about what "non-essential HTTP headers" mean,
especially without being much more specific about these. and providing
clear guidance in the core specification.  Implementations leaving out
required headers without clear guidance seems likely to lead to
interoperable implementations.

Separately on privacy considerations...

>From a related thread on DNSOP where Colm MacCárthaigh raised this, do we
need to provide guidance on the rrset ordering side-channel?  Or does that
apply as a general issue for DPRIVE?  The relevant issue is that since
cached rrset responses will have a stable ordering of IP addresses to try,
if clients receive the same rrset over DoH and go through the IPs in the
same order, this makes it visible to an external observer which cached
response the two clients received, especially if the same set of IPs share
a wide variety of different hostnames.   Recommending the client permute
the (unordered-by-specification) rrset received and try responses in a
pseudo-random order (absent local performance information preferring some
over others) both reduces opportunities for this side-channel attack.
Regardless of the side-channel privacy issues here, since DoH responses may
be cached by design and won't get randomized/roundrobin/etc rrset-sorting
applied to each response it likely makes sense to give the guidance that
DoH clients should do pseudo-random sorting of received rrsets of only for
better load balancing across IPs in the rrsets.

     Erik

---

From: nusenu <[email-masked]>
Date: Wed, 20 Jun 2018 00:14:00 +0000

> Privacy Considerations

thanks for writing this section.

I copied it to the file [1]
changed the formatting a bit [2]
and made some minor changes [3]:

- add reference to RFC7858
- be more specific about where DNS traffic is encrypted
Should we add recursive-to-recursive as well? (since that
can be done with DoH as well)

- replace 'resolver' with 'DoH server'
- SHOULD not -> SHOULD NOT (RFC2119)

These are individual tiny commits so it is easier to cherry pick
what one likes and what not.

[1] https://github.com/nusenu/draft-ietf-doh-dns-over-https/commit/dde0af2d97b92c65f0d2ded239a98c15824e2650
[2] https://github.com/nusenu/draft-ietf-doh-dns-over-https/commit/93f5dabe5197323f568a61c4f5d4f2313c7260d5
[3] https://github.com/nusenu/draft-ietf-doh-dns-over-https/commits/privacy_considerations

---

From: Petr Špaček <[email-masked]>
Date: Wed, 20 Jun 2018 10:38:54 +0200

> Do you know RFC7873? Yes, there is already a Cookie system for traditional DNS protocol. And many public DNS services are already using it to protect against DDoS attack.

It is very important to note that DNS cookies are, unlike HTTP cookies, 
designed to just verify IP addresses and nothing else.

I.e. an properly implemented DNS cookies will change once client's IP 
address changes so DNS cookies cannot be used to track client who is 
moving across different networks. This is very different property when 
compared to traditional HTTP cookies which easily facilitate tracking.

> My suggestions is to give the user an option to disable Cookies, or limit Cookies to a very short lifetime (e.g. 2 minutes).

Wouldn't it cause all the DDoS mitigations work only for two minutes?

-- 
Petr Špaček  @  CZ.NIC