Subject: [Doh] New Privacy Considerations Section Proposal

From: Patrick McManus <[email-masked]>
Date: Wed, 20 Jun 2018 18:05:39 -0400

Hi All,

The authors have a proposed privacy considerations section available as a
PR at: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 and
a snapshot is also included at the end of this email. (though obviously the
PR will be a living document).

First, thanks for the all the comments and especially to Sara for some of
the significant text that made its way into the draft text.

The text does not, cannot really, describe the whole universe of
http/tls/tcp/ip fingerprinting - but it does raise it as an issue and try
to give enough illustrative examples to motivate consideration of these
things in your implementation. And in the end, that's its recommendation -
consider these things and don't use them blindly. The construction that
"DoH inherits the HTTPS profile so understand that please" seems most apt
and in scope.

It would be really great if we had something published in the HTTP space
that deal with this. We don't AFAICT, and that's feedback Mark and I have
already started noodling over for HTTPbis. (If we had it, the DoH text
would be shorter :))

Comments and discussion are of course welcome - its just a pull request.

-Patrick

---

# Privacy Considerations {#PrivacyConsiderations}

{{RFC7626}} discusses DNS Privacy Considerations in both "On the
wire" (Section 2.4), and "On the server" (Section 2.5) contexts. This
is also a useful framing for DoH's privacy considerations.

## On The Wire {#OnTheWire}

DoH encrypts DNS traffic and requires authentication of the
server. This mitigates both passive surveillance {{RFC7258}} and
active attacks attempting to divert DNS traffic to rogue servers
({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} provides
similar protections, while direct UDP and TCP based transports are
vulnerable to this class of information leak.

Additionally, the use of the HTTPS default port 443 and the ability to
mix DoH traffic with other HTTPS traffic on the same connection can
deter on-path devices from interfering with DNS operations and make
DNS traffic analysis more difficult.

## On The Server {#OnTheServer}

A DoH application is built on IP, TCP, TLS, and HTTP. Each layer
contains one or more common features that can be used to correlate
different queries to the same identity. DoH inherits the privacy
properties of the HTTPS stack and is not known to introduce new
concerns beyond that of HTTPS.

At the IP level, the client address provides obvious correlation
information. This can be mitigated by use of a NAT, proxy, VPN, or
simple address rotation over time. It may be aggravated by use of a
DNS server that can correlate real-time addressing information with
other personal identifiers, such as when a DNS server and DHCP server
are operated by the same entity.

TCP-based solutions may seek performance through the use of TCP Fast
Open {{RFC7413}}. The cookies used in TCP Fast Open allow servers to
correlate different TCP sessions together.

TLS based implementations often achieve better handshake performance
through the use of some form of session resumption mechanism such as
session tickets {{RFC5077}}. Session resumption creates trivial
mechanisms for a server to correlate different TLS connections
together.

HTTP's feature set can also be used for identification and tracking in
a number of different ways. For example, authentication request header
fields explicitly identify profiles in use, and HTTP Cookies are
designed as an explicit state tracking mechanism between the client
and serving site and often are used as an authentication mechanism.

Additionally, the User-Agent and Accept-Language request header fields
often convey specific information about the client version or locale.
This facilitates content negotiation and operational work-arounds for
implementation bugs. Request header fields that control caching
can expose state information about a subset of the client's
history. Mixing DoH requests with other HTTP requests on the same
connection also provides an opportunity for richer data correlation.

Implementations of DoH clients and servers need to consider the benefit
and privacy impact of all these features, and their deployment context,
when deciding whether or not to enable them.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 20 Jun 2018 15:14:21 -0700

Repeating the comment I made at Github:

Is there a reason not to make a recommendation for the case of a DOH-only
service?  The current text says:

Would you consider a recommendation like "For DOH clients which do not
intermingle DOH requests with other HTTP suppression of these headers and
other potentially identifying headers is an appropriate data minimization
strategy."?

Ted

On Wed, Jun 20, 2018 at 3:05 PM, Patrick McManus <[email-masked]>
wrote:

> PR at: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200
> and a snapshot is also included at the end of this email. (though obviously
> the PR will be a living document).
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Jun 2018 22:26:07 +0000

On Jun 20, 2018, at 3:14 PM, Ted Hardie <[email-masked]> wrote:
> Is there a reason not to make a recommendation for the case of a DOH-only service?  The current text says:
> 
> Would you consider a recommendation like "For DOH clients which do not intermingle DOH requests with other HTTP suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy."?

That could be added, but it would need a *lot* more text because your proposed text only deals with one layer (HTTP) while the text above it also talks about fingerprinting with TLS, TCP, and IP (in reverse order). The WG can decide whether adding recommendations for just one layer is worthwhile or possibly misleading about the overall privacy.

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Wed, 20 Jun 2018 15:29:44 -0700

Hmm, we should probably pick one place to have this conversation.  In the
mean time, here's my reply to Paul:

It was only an example, and I would be happy to expand. That said, I think
this is the most likely source of leakage: folks using a general purpose
HTTP subsystem that carries information not needed for DOH requests.
Actually recommending data minimization there, rather than saying "it
should be considered" seems like a worthwhile thing to do in my personal
opinion.

Ted

On Wed, Jun 20, 2018 at 3:26 PM, Paul Hoffman <[email-masked]>
wrote:

> That could be added, but it would need a *lot* more text because your
> proposed text only deals with one layer (HTTP) while the text above it also
> talks about fingerprinting with TLS, TCP, and IP (in reverse order). The WG
> can decide whether adding recommendations for just one layer is worthwhile
> or possibly misleading about the overall privacy.
>
> --Paul Hoffman

---

From: Patrick McManus <[email-masked]>
Date: Wed, 20 Jun 2018 19:03:15 -0400

> other potentially identifying headers is an appropriate data minimization
there are some practical problems there. Big picture you need to weigh the
reasons these things get used in your implementation decisions. Its not
like TLS didn't know they had built a tracker with session tickets, yet
dprive recommended its use anyhow :)

every http feature has a reason an implementation might want want it in
doh. cookies can do useful things for auth. new compression algorithms
(which create a fingerprint on introduction just as surely as UA does)
enable better performance. etc.. UA strings have kept the web runinng, for
good and bad, across many unanticipated bugs for many years.. I'm not
saying those arguments win the day but its not really DoH's place to change
the properties of HTTP. Alt-Service provides great load balancing and
protocol evolution, but its basically a cache with a tracking implication
too.

It is an important goal of this work to leverage the HTTP ecosystem -
stripping out all the HTTP parts and leaving a tunnel doesn't give it any
value.

The picture is also complicated by the end to end message semantics of http
headers and how they interact with the hop to hop transport semantics of
the client or server. i.e. the notion of intermingle is not e2e, but
headers are. That's not really a driver, but something to keep in mind when
considering the limitations of text.

I'm more inclined in general to use words along the lines of "should use
the minimal set of data that can achieve the desired feature set." if
that's helpful, but I'm not eager to start working through individual
design decisions.

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 Jun 2018 18:54:31 -0500

[as an individual]

I agree with Patrick's analysis here, and think the proposed text (plus 
the "minimal set of data" statement below) is likely to serve the 
purpose well. In particular, I agree with Patrick that the various 
features that have been cited so far each serve a useful purpose, and 
that such purposes may have a place in DoH deployments. Giving 
implementors a heads up about the privacy trade-offs seems appropriate. 
Mandating (MUST or SHOULD) that DoH runs over a minimal profile of HTTP 
seems to remove several of the advantages of using HTTP at all.

/a

On 6/20/18 6:03 PM, Patrick McManus wrote:
>
>
> On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Would you consider a recommendation like "For DOH clients which do
>     not intermingle DOH requests with other HTTP suppression of these
>     headers and other potentially identifying headers is an
>     appropriate data minimization strategy."?
>
>
> there are some practical problems there. Big picture you need to weigh 
> the reasons these things get used in your implementation decisions. 
> Its not like TLS didn't know they had built a tracker with session 
> tickets, yet dprive recommended its use anyhow :)
>
> every http feature has a reason an implementation might want want it 
> in doh. cookies can do useful things for auth. new compression 
> algorithms (which create a fingerprint on introduction just as surely 
> as UA does) enable better performance. etc.. UA strings have kept the 
> web runinng, for good and bad, across many unanticipated bugs for many 
> years.. I'm not saying those arguments win the day but its not really 
> DoH's place to change the properties of HTTP. Alt-Service provides 
> great load balancing and protocol evolution, but its basically a cache 
> with a tracking implication too.
>
> stripping out all the HTTP parts and leaving a tunnel doesn't give it 
> any value.
>
> The picture is also complicated by the end to end message semantics of 
> http headers and how they interact with the hop to hop transport 
> semantics of the client or server. i.e. the notion of intermingle is 
> not e2e, but headers are. That's not really a driver, but something to 
> keep in mind when considering the limitations of text.
>
> I'm more inclined in general to use words along the lines of "should 
> use the minimal set of data that can achieve the desired feature set." 
> if that's helpful, but I'm not eager to start working through 
> individual design decisions.
>
>
>
>

---

From: "Hewitt, Rory" <[email-masked]>
Date: Thu, 21 Jun 2018 00:02:42 +0000

I like Patrick's proposed wording along the lines of "...should use the 
minimal set of data that can achieve the desired feature set.", but I also 
like Ted's more explicit suggestion.

Perhaps this combination?:

"DoH clients should use the minimal set of data (e.g. headers, cookies) that 
can achieve the desired feature set whilst minimizing potentially identifying 
information being passed."

Just my $0.02...

Thanks,

Rory

From: Adam Roach [mailto:[email-masked]]
Sent: Wednesday, June 20, 2018 4:55 PM
To: Patrick McManus <[email-masked]>; Ted Hardie <[email-masked]>
Cc: DoH WG <[email-masked]>
Subject: Re: [Doh] New Privacy Considerations Section Proposal

[as an individual]

I agree with Patrick's analysis here, and think the proposed text (plus the 
"minimal set of data" statement below) is likely to serve the purpose well. In 
particular, I agree with Patrick that the various features that have been 
cited so far each serve a useful purpose, and that such purposes may have a 
place in DoH deployments. Giving implementors a heads up about the privacy 
trade-offs seems appropriate. Mandating (MUST or SHOULD) that DoH runs over a 
minimal profile of HTTP seems to remove several of the advantages of using 
HTTP at all.

/a

On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie <[email-masked] 
<mailto:[email-masked]> > wrote:

there are some practical problems there. Big picture you need to weigh the 
reasons these things get used in your implementation decisions. Its not like 
TLS didn't know they had built a tracker with session tickets, yet dprive 
recommended its use anyhow :)

every http feature has a reason an implementation might want want it in doh. 
cookies can do useful things for auth. new compression algorithms (which 
create a fingerprint on introduction just as surely as UA does) enable better 
performance. etc.. UA strings have kept the web runinng, for good and bad, 
across many unanticipated bugs for many years.. I'm not saying those arguments 
win the day but its not really DoH's place to change the properties of HTTP. 
Alt-Service provides great load balancing and protocol evolution, but its 
basically a cache with a tracking implication too.

The picture is also complicated by the end to end message semantics of http 
headers and how they interact with the hop to hop transport semantics of the 
client or server. i.e. the notion of intermingle is not e2e, but headers are. 
That's not really a driver, but something to keep in mind when considering the 
limitations of text.

I'm more inclined in general to use words along the lines of "should use the 
minimal set of data that can achieve the desired feature set." if that's 
helpful, but I'm not eager to start working through individual design 
decisions.

_______________________________________________
Doh mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/doh 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=7boz0IZ1KBlcynrJRZvHUlL6gh1y4uzb-x87ZvAPKpg&s=avFqKXoSyMVxMlVyRiyAICtyhhiq6eXCDBvftWeYx14&e=>

---

From: nusenu <[email-masked]>
Date: Thu, 21 Jun 2018 00:06:00 +0000

I like the proposal but I agree with Ted, that it should be expanded
and data minimization should be explicitly recommended instead of considered.

I also found the comparison of DoH with DoT (RFC7858) from a privacy
perspective in Sara's text [1] useful to help understand
the privacy delta of these protocols.

"DNS-over-TLS {{RFC7858}}, for example, would normally contain no client 
identifiers in the DNS messages and a recursive 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 DoH server being able to identify 
the source of individual DNS requests not only to a specific end user device 
but to a specific application."

> DoH inherits the privacy properties of the HTTPS stack and 
> is not known to introduce new concerns beyond that of HTTPS.

It does not introduce new concerns when compared with HTTPS 
but it does introduce new privacy converns when compared with 
DNS over UDP, TCP or TLS (RFC7858),
namely the significantly increased fingerprintability of the DoH DNS client
when compared to other types of DNS clients 
and the direct linking of DNS with HTTP traffic when a DoH server is not
exclusively used for DoH.

> information. This can be mitigated by ...
> 
> TCP-based solutions ...
> 
> TLS based implementations ...
> 
> HTTP's feature set can also be used for identification and tracking

The IP layer paragraph includes mitigations, the paragraphs about 
the other layers are missing mitigations.

> when deciding whether or not to enable them.

I think it would be better to at least recommend privacy-by-default settings and values 
instead of leaving it completely up to the implementors - even if we can not
enumerate all possible privacy issues and mitigations.

[1] https://mailarchive.ietf.org/arch/msg/doh/BFYfWTrnxU0iHeGVqvbIMlGJ6lA

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

---

From: Patrick McManus <[email-masked]>
Date: Wed, 20 Jun 2018 20:58:09 -0400

Hi Nusenu,

> DNS over UDP, TCP or TLS (RFC7858),

I started to go down this path, but it pretty quickly became clear that
comprehensive treatment of this kind of comparison is a different document
- though I think describing things in layers does a decent job of pointing
out where these various properties come into play. DoH needs to describe
the properties of DoH.. the proposed text certainly doesn't try and hide
from the fingerprintability of the http system doh is using.

> the other layers are missing mitigations.
those mitigations are there to provide context/scope to the addressing
problem - not advice on how to mitigate it :) For most of the other
features the mitigation is "don't use it" which of course has a cost.

---

From: nusenu <[email-masked]>
Date: Thu, 21 Jun 2018 11:08:00 +0000

> from the fingerprintability of the http system doh is using.

So because a comprehensive treatment is hard and obviously not the primary goal of the
document a comparative statement of the privacy implications of DoH wrt other DNS protocols 
from Sara's text is no longer mentioned at all?

> features the mitigation is "don't use it" which of course has a cost.

I don't think privacy is a binary all or nothing decision.

I'd like to understand the reasoning for NOT including specific privacy friendly 
recommendations in the document, because currently the document mentions
the high level issues but doesn't give specific advise on what to do about it
- the implementors are basically on their own -
and there have already been given specific statements from multiple persons on this 
list on what could be done to at least address the most obvious issues (i.e. UA) [1][2]

[1] https://mailarchive.ietf.org/arch/msg/doh/vHjITrOMhWSdrozGFe4-eGNMEJc
[2] https://mailarchive.ietf.org/arch/msg/doh/BFYfWTrnxU0iHeGVqvbIMlGJ6lA
-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

---

From: Howard Chu <[email-masked]>
Date: Thu, 21 Jun 2018 12:22:01 +0100

> minimal profile of HTTP seems to remove several of the advantages of using 

That's overstating things. It seems the primary benefit is being able to hide 
DoH traffic within standard HTTPS traffic, making it more difficult to filter 
out at firewalls. That benefit remains, even if barebones HTTP requests are used.

>>     intermingle DOH requests with other HTTP suppression of these headers
>>     and other potentially identifying headers is an appropriate data
>>     minimization strategy."?

I would expect this to be the common case - most of the time, clients' HTTP(s) 
traffic will be to a wide variety of web servers, but only a single DNS/DoH 
server. And that particular DNS/DoH server is unlikely to be serving any 
interesting web pages for any clients. As such, the frequency of intermingled 
connections should be low-to-zero.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 21 Jun 2018 13:29:07 +0200 (CEST)

On Thu, 21 Jun 2018, Howard Chu wrote:

> that particular DNS/DoH server is unlikely to be serving any interesting web 
> pages for any clients. As such, the frequency of intermingled connections 
> should be low-to-zero.

That's a rather pessimistic view of the DoH future.

I think it is likely that some DoH server operators will be companies with 
distributed presence so that they can offer proximity to users; CDNs and the 
likes. CDNs also host web sites. They should thus be perfect candidates for 
serving both web content and DoH requests over the same connections. 
Especially in combination with the ORIGIN frame etc.

-- 

  / daniel.haxx.se

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 21 Jun 2018 12:34:20 +0100

> On 21 Jun 2018, at 01:58, Patrick McManus <[email-masked]> wrote:
> 
> Hi Nusenu,
> 
> On Wed, Jun 20, 2018 at 8:06 PM, nusenu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I started to go down this path, but it pretty quickly became clear that comprehensive treatment of this kind of comparison is a different document - though I think describing things in layers does a decent job of pointing out where these various properties come into play. DoH needs to describe the properties of DoH.. the proposed text certainly doesn't try and hide from the fingerprintability of the http system doh is using.

But I also support (as other have voiced) at least a statement that it does introduce new concerns compared with 
DNS over UDP, TCP or TLS (RFC7858) which is missing from the new text.  Also a clear justification of why the design decisions were made (if I’ve heard the current arguments correctly).

I propose:

OLD:
“DoH inherits the privacy properties of the HTTPS stack and is not known to introduce new concerns beyond that of HTTPS."

NEW:
“As a deliberate design choice DoH inherits the privacy properties of
the HTTPS stack and is not known to introduce new concerns beyond that of HTTPS.
As a consequence, however, it does introduce new privacy concerns when compared
with DNS over UDP, TCP or TLS (RFC7858). The rationale for this decision is that 
retaining the ability to leverage the full functionality of the HTTP ecosystem is more
important than placing any constraints on this new protocol based on privacy considerations."

> those mitigations are there to provide context/scope to the addressing problem - not advice on how to mitigate it :) For most of the other features the mitigation is "don't use it" which of course has a cost.

But that cost would be low for a system resolver for example that could easily gain many benefits of DoH without needing to include hardly any of the HTTP bells and whistles. The current assumptions are very browser centric. 

I support adding the text as suggested by others e.g.
"In making this evaluation DoH clients should use the minimal set of data (e.g. headers, cookies) that can achieve the desired feature set whilst minimizing potentially identifying information being passed. For DOH clients which do not intermingle DOH requests with other HTTP messages suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy.”

Sara.

---

From: nusenu <[email-masked]>
Date: Thu, 21 Jun 2018 11:41:00 +0000

> information being passed."

I like this as a start with the following modification:
should -> SHOULD

and

followed by what a minimal example DoH client request looks like and the specific
advice that Sara gave in her Privacy Consideration section wrt header (specifically UA).

---

From: nusenu <[email-masked]>
Date: Thu, 21 Jun 2018 11:45:00 +0000

> I propose:
> 
> OLD: “DoH inherits the privacy properties of the HTTPS stack and is
> not known to introduce new concerns beyond that of HTTPS."
> 
> NEW: “As a deliberate design choice DoH inherits the privacy
> concerns beyond that of HTTPS. As a consequence, however, it does
> introduce new privacy concerns when compared with DNS over UDP, TCP
> or TLS (RFC7858). The rationale for this decision is that retaining
> the ability to leverage the full functionality of the HTTP ecosystem
> is more important than placing any constraints on this new protocol
> based on privacy considerations."

+1 this is a rather clear statement.

thanks for that!

---

From: bert hubert <[email-masked]>
Date: Thu, 21 Jun 2018 13:50:23 +0200

> important than placing any constraints on this new protocol based on privacy considerations."

+1 !

> "In making this evaluation DoH clients should use the minimal set of data
> (e.g.  headers, cookies) that can achieve the desired feature set whilst
> minimizing potentially identifying information being passed.  For DOH
> clients which do not intermingle DOH requests with other HTTP messages
> suppression of these headers and other potentially identifying headers is
> an appropriate data minimization strategy.”

+1 !

	Bert

---

From: Mateusz Jończyk <[email-masked]>
Date: Thu, 21 Jun 2018 13:58:02 +0200

> advice that Sara gave in her Privacy Consideration section wrt header (specifically UA).
I am afraid that ensuring that the minimal set of data is being used may be
difficult in practice, for example in simpler implementations that do not have
complete control over the stack. For example, it may be non-trivial to disable
TCP Fast Open when using a particular networking library.

Additionally, fulfilling this requirement to the letter would require insight
into the whole protocol stack, which would require much knowledge and expertise.
It should not be assumed that DOH implementers are knowledgeable about TCP Fast
Open or HTTPS session tickets, for example.

What is more, there has been talk about using DOH in JavaScript.

I would rather support the previous text in the PR:

Greetings,
Mateusz Jończyk

---

From: Howard Chu <[email-masked]>
Date: Thu, 21 Jun 2018 12:58:57 +0100

> That's a rather pessimistic view of the DoH future.

It's a realistic view of devices coming preconfigured to use e.g. Google's DNS 
servers.

> Especially in combination with the ORIGIN frame etc.

Those companies may indeed arise, but the vast majority of users will never 
change their default DNS settings to point to them.

---

From: nusenu <[email-masked]>
Date: Thu, 21 Jun 2018 12:09:00 +0000

Mateusz Jończyk wrote:
> complete control over the stack. 

Since this is about a SHOULD and not a mandatory requirement (MUST) there is no
need to be afraid to fail to implement a SHOULD recommendation?

---

From: Howard Chu <[email-masked]>
Date: Thu, 21 Jun 2018 13:10:22 +0100

Howard Chu wrote:
>>> that particular DNS/DoH server is unlikely to be serving any interesting 
>>> web pages for any clients. As such, the frequency of intermingled 

An additional point - it's been easy enough to launch DDoS attacks against 
dedicated DNS infrastructure in the past. If you combine DNS traffic and real 
HTTP traffic in the same server, it will become even easier to overload these 
servers and knock out DNS service.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Jun 2018 08:57:18 -0400

On Thu, Jun 21, 2018 at 7:22 AM, Howard Chu <[email-masked]> wrote:

>
> I would expect this to be the common case - most of the time, clients'
> HTTP(s) traffic will be to a wide variety of web servers, but only a single
> DNS/DoH serve

I strongly disagree with the view point that DoH clients and servers are
dedicated only to DoH. The granularity of DoH is a URI (configured via a
template).

I understand that the use case of "use HTTPS's port and ALPN" to do
something akin to DNS-over-TLS is the attractive use case for some. But
we're using HTTP and trying to align with the ecosystem. Its not a tunnel.
The introduction discusses some of this directly, and some other text
addresses it obliquely. Note that a server may support more than one URI
and that we jettisoned the .well-known of an earlier draft.. that's all
because URIs are the granularity of HTTP and that is also the scope of DoH.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Jun 2018 08:57:29 -0400

> from Sara's text is no longer mentioned at all?
I feel like it is absolutely mentioned!

The text makes clear that issues arise at the IP, TCP, TLS, and HTTPS
layers.

UDP-based DNS suffers from IP issues, TCP-based DNS suffers from TCP and IP
based issues, DNS over TLS suffers from IP, TCP, and TLS  based issues, and
DoH adds HTTP issues to the mix. The DoH spec is going to focus on DoH.. if
another document would like to comprehensively discuss all of this that's
fine by me but its not practical to do here.

I'll add a small clarifying bit to the text for people to try out - but
this is already most of the text.

> recommendations in the document, because currently the document mentions

DoH uses and requires HTTP but does not redefine it. DoH is not a mere
tunnel for DNS and applications should leverage what features fit their
needs. The specification(s) for those features are where you need to look
to make a decision or you turn things over to a library.

the high level issues but doesn't give specific advise on what to do about
> it

this is non-normative considerations text - it is highlighting what you
need to consider. The primary consideration is that you are now in the HTTP
ecosystem. A couple other messages have asked to highlight that the HTTP
ecosystem is different than the DNS ecosystem and I'm fine with including
that.

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 21 Jun 2018 14:56:50 +0100

> On 21 Jun 2018, at 13:57, Patrick McManus <[email-masked]> wrote:
> 
> 
> DoH uses and requires HTTP but does not redefine it. DoH is not a mere tunnel for DNS and applications should leverage what features fit their needs. The specification(s) for those features are where you need to look to make a decision or you turn things over to a library.

One further issue - RFC7626 (DNS Privacy considerations) is currently an informative reference. If the draft  is going to argue that all implementors must make their own decision about balancing HTTP functionality against privacy then RFC7626 is a document they should be required to read. I think this should be a normative reference.

Nit: Section 2.5 in that document is called ‘In the server’ not ‘On the server’ as in the current PR text. 

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 21 Jun 2018 15:00:38 +0100

> On Thu, Jun 21, 2018 at 7:22 AM, Howard Chu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I would expect this to be the common case - most of the time, clients' HTTP(s) traffic will be to a wide variety of web servers, but only a single DNS/DoH serve
> 
> I strongly disagree with the view point that DoH clients and servers are dedicated only to DoH. The granularity of DoH is a URI (configured via a template).
> 
> I understand that the use case of "use HTTPS's port and ALPN" to do something akin to DNS-over-TLS is the attractive use case for some.

To many members of this working group in fact. There are already 2 implementations in progress that fall into this category - Stubby using DoH as a system resolver and dnsdist as a DNS resolver that offers service over DoH. These are legitamate use cases and running code that should be recognised in this draft even though they differ from the browser centric view of:

>  But we're using HTTP and trying to align with the ecosystem. Its not a tunnel..

There are many that want to use DoH and align it with the DNS ecosystem where it might be akin to just a tunnel and yet still provide distinct benefits.

Sara.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Jun 2018 10:16:33 -0400

On Thu, Jun 21, 2018 at 9:56 AM, Sara Dickinson <[email-masked]> wrote:

>
>
> One further issue - RFC7626 (DNS Privacy considerations) is currently an
> informative reference. If the draft  is going to argue that all
> implementors must make their own decision about balancing HTTP
> functionality against privacy then RFC7626 is a document they should be
> required to read. I think this should be a normative reference.
>

unfortunately 7626 is informational and making it normative from DoH would
(aiui) be a down reference that isn't allowed from a standards track
document.

> server’ as in the current PR text.
got it. thanks.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jun 2018 07:24:54 -0700

On Thu, Jun 21, 2018 at 7:16 AM, Patrick McManus <[email-masked]>
wrote:

>> required to read.. I think this should be a normative reference.
>>
>

You actually can do that. See: https://tools.ietf.org/rfcmarkup/8067

-Ekr

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 21 Jun 2018 15:25:55 +0100

> On 21 Jun 2018, at 15:16, Patrick McManus <[email-masked]> wrote:
> 
> 
> 
> On Thu, Jun 21, 2018 at 9:56 AM, Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> unfortunately 7626 is informational and making it normative from DoH would (aiui) be a down reference that isn't allowed from a standards track document.

Good point, well made. I missed that. :-)

---

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Jun 2018 10:35:46 -0400

but ekr counters us both - seems like 8067 fits the documents at hand well.
happy to make 7626 normative knowing that.

---

From: nusenu <[email-masked]>
Date: Thu, 21 Jun 2018 16:08:00 +0000

> The text makes clear that issues arise at the IP, TCP, TLS, and HTTPS

by "comparative statement" I was referring to 
"
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.
"

> important than placing any constraints on this new protocol based on privacy considerations."

that hasn't gotten any feedback from the draft authors yet.

[1] https://mailarchive.ietf.org/arch/msg/doh/_ju-J52e5cf7UNpgwhCbq5pln5Y

> needs. 

Understood. Now it primarily about making this clear in the draft and the
proposed paragraph above is IMHO doing that very well.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 21 Jun 2018 12:21:25 -0400

> that hasn't gotten any feedback from the draft authors yet.
working on it :)

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Jun 2018 10:26:47 -0700

On Wed, Jun 20, 2018 at 4:54 PM, Adam Roach <[email-masked]> wrote:

> the "minimal set of data" statement below) is likely to serve the purpose
> well. In particular, I agree with Patrick that the various features that
> have been cited so far each serve a useful purpose, and that such purposes
> may have a place in DoH deployments. Giving implementors a heads up about
> the privacy trade-offs seems appropriate. Mandating (MUST or SHOULD) that
> DoH runs over a minimal profile of HTTP seems to remove several of the
> advantages of using HTTP at all.
>
> Note that this is not actually what I said--I said "run without specific
headers *when you are not interleaving DOH with other HTTP requests*".
That's a use case where some key advantages of using HTTP (traversal,
particularly) are maintained without affecting the other use cases which
might prefer more general integration.

Ted

> http headers and how they interact with the hop to hop transport semantics
> of the client or server. i.e. the notion of intermingle is not e2e, but
> Doh mailing [email-masked]://www.ietf.org/mailman/listinfo/doh
>
>
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Jun 2018 10:43:51 -0700

On Thu, Jun 21, 2018 at 5:57 AM, Patrick McManus <[email-masked]>
wrote:

> we're using HTTP and trying to align with the ecosystem.
>

There is more than one HTTP ecosystem, and forcing some use cases to behave
as if they are using it differently does not make sense.  A DOH-only
request stream does not need to send information on accept-language; why
would it do so?

Ted

> Its not a tunnel. The introduction discusses some of this directly, and
> some other text addresses it obliquely. Note that a server may support more
> than one URI and that we jettisoned the .well-known of an earlier draft..
> that's all because URIs are the granularity of HTTP and that is also the
> scope of DoH.
>
>
>
>
>
>
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Jun 2018 14:42:44 -0500

On 6/21/18 6:22 AM, Howard Chu wrote:
> Adam Roach wrote:
>> [as an individual]
>>
>> I agree with Patrick's analysis here, and think the proposed text 
>> (plus the "minimal set of data" statement below) is likely to serve 
>> the purpose well. In particular, I agree with Patrick that the 
>> various features that have been cited so far each serve a useful 
>> purpose, and that such purposes may have a place in DoH deployments. 
>> Giving implementors a heads up about the privacy trade-offs seems 
>> appropriate. Mandating (MUST or SHOULD) that DoH runs over a minimal 
>> profile of HTTP seems to remove several of the advantages of using 
>> HTTP at all.
>
> That's overstating things. It seems the primary benefit is being able 
> to hide DoH traffic within standard HTTPS traffic, making it more 
> difficult to filter out at firewalls. That benefit remains, even if 
> barebones HTTP requests are used. 

Note that I didn't say "all" or "most" -- I said "several." If all we 
wanted was putting DNS requests over connections that are difficult to 
distinguish from ordinary HTTPS traffic, then we could have 
informatively described the use of HTTP CONNECT to set up RFC 7858 
connections and had a much simpler document.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Jun 2018 14:51:39 -0500

On 6/21/18 12:43 PM, Ted Hardie wrote:
> There is more than one HTTP ecosystem, and forcing some use cases to 
> behave as if they are using it differently does not make sense.  A 
> DOH-only request stream does not need to send information on 
> accept-language; why would it do so?

Under the proposed guidance ("In making this evaluation DoH clients 
should use the minimal set of data
(e.g.  headers, cookies) that can achieve the desired feature set"), it 
would not do so.

/a

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 28 Jun 2018 10:37:56 +0400

There is the mention of padding which was added in the security
section. RFC 7830 talks about padding but does not mention padding
length. I've made a PR here for pointing to
draft-ietf-dprive-padding-policy which discusses padding length
choices: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/207.