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

[Paul Hoffman <[e-mail]>]

On Jun 22, 2018, at 8:34 AM, Mateusz Jończyk <[e-mail]> wrote:
> 
> Signed PGP part
> W dniu 21.06.2018 o 20:43, Patrick McManus pisze:
>> ## 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 sentence above is misleading. We are talking about DOH, not DNS over TLS.

Earlier, the WG wanted the document to compare (where appropriate) DoH and DoT. It seems appropriate to do so in the privacy considerations to show that DoH has one more layer that can  make user tracking more possible.

>> 
>> 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.
> 
> I have been thinking that a DoH client would open a long-running connection to a
> DoH server. In such a case, request correlation could be simple and we should
> drop the "is not known to introduce new concerns" sentence.

Both RFC 7766 (DNS in TCP) and RFC 7858 (DNS in TLS) recommend opening long-running connections, and explain the operational pros and cons of doing so.

>> 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}}..
> 
> Double dot here.

Thanks; fixed in editor's copy.

> 
>> 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.
> 
> "and server" would be better.

Agree; fixed in editor's copy.

> 
>> 
>> [...]
>> 
>> 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.
> 
> It would be IMHO better to write "Implementations are advised to expose the
> minimal set of data..." to avoid the use of the word "should" (as this is not a
> RFC2119 SHOULD and IMHO shouldn't be, as I explained previously on the list [1]).

Will do.

--Paul Hoffman