[Doh] Privacy Considerations Text (#2)

[Patrick McManus <[e-mail]>]

Hi All,

We may be getting close to bridging the important points here - so we've
made an update to the PR. (its still not merged into the working copy, but
it has changed). and we can iterate from there. Thank you for the comments,
and especially text proposals - they really help.

The live copy is at
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 and I'll
snapshot it again at the end of this email

The deltas make more explicit comparisons between DoH and Do(TLS), calls
out some rationale about the full ecosystem in the same text that asks you
to consider the cost/benefits of http features, and includes the new text
about a minimal data set.

-Patrick

# Privacy Considerations {#PrivacyConsiderations}

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

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

## In The Server {#InTheServer}

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

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.

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.

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
should expose the minimal set of data needed to achieve the desired
feature set.