Draft: draft-ietf-doh-dns-over-https-latest

Commentary: Is there a reason not to make a recommendation for the case of a DOH - only service ? The current text says : 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 . 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 , 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 . 
 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 . 
 Agreed with  ( on the list ) that this conversation should be on the list . Locking it here . 
 I have unlocked the comments so that people can propose specific wording changes as diffs in the PR itself ; most questions and suggestions should be done on the list .
Paragraph (version B):
PrivacyConsiderations and Security discuss additional considerations
for the integration with HTTP.
Paragraph (version B):
RFC7626 discusses DNS Privacy Considerations in both "On the wire"
(Section 2.4), and "In the server" (Section 2.5) contexts.  This is
also a useful framing for DoH's privacy considerations.
Paragraph (version B):
DoH encrypts DNS traffic and requires authentication of the server.
This mitigates both passive surveillance RFC7258 and active attacks
that attempt 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 attack.
Paragraph (version B):
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 unprivileged on-path devices from interfering with DNS
operations and make DNS traffic analysis more difficult.
Paragraph (version B):
A DoH implementation is built on IP, TCP, TLS, and HTTP.  Each layer
contains one or more common features that can be used to correlate
queries to the same identity.  DNS transports will generally carry
the same privacy properties of the layers used to implement them.
For example, the properties of IP, TCP, and TLS apply to DNS over TLS
implementations.
Paragraph (version B):
The privacy considerations of using the HTTPS layer in DoH are
incremental to those of DNS over TLS.  DoH is not known to introduce
new concerns beyond those associated with HTTPS.
Paragraph (version B):
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.
Paragraph (version B):
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 TCP sessions together.
Paragraph (version B):
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 TLS connections together.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
The DoH protocol design allows applications to fully leverage all the
features of the HTTP ecosystem, including features not enumerated
here.  Implementations of DoH clients and servers need to consider
the benefit and privacy impact of these features, and their
deployment context, when deciding whether or not to enable them.
Implementations are advised to expose the minimal set of data needed
to achieve the desired feature set.
Paragraph (version B):
Determining whether or not a DoH implementation requires HTTP cookie
RFC6265 support is particularly important because HTTP cookies are
the primary state tracking mechanism in HTTP.  HTTP Cookies SHOULD
NOT be accepted by DOH clients unless they are explicitly required by
a use case.