Re: [Doh] Privacy Considerations Text (#2)

[Eric Rescorla <[e-mail]>]

Can you please enable comments on the PR so that people can provide
detailed feedback

-Ekr


On Thu, Jun 21, 2018 at 11:43 AM, Patrick McManus <[e-mail]>
wrote:

> 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.
>
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>
>