[Doh] New Privacy Considerations Section Proposal
Patrick McManus <pmcmanus@mozilla.com> Wed, 20 June 2018 22:05 UTC
Return-Path: <pmcmanus@mozilla.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58623130EED for <doh@ietfa.amsl.com>; Wed, 20 Jun 2018 15:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVhNChmBlL8D for <doh@ietfa.amsl.com>; Wed, 20 Jun 2018 15:05:42 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 69C50130F14 for <doh@ietf.org>; Wed, 20 Jun 2018 15:05:42 -0700 (PDT)
Received: from mail-ot0-f173.google.com (mail-ot0-f173.google.com [74.125.82.173]) by linode64.ducksong.com (Postfix) with ESMTPSA id 50F443A03B for <doh@ietf.org>; Wed, 20 Jun 2018 18:05:40 -0400 (EDT)
Received: by mail-ot0-f173.google.com with SMTP id 101-v6so1277771oth.4 for <doh@ietf.org>; Wed, 20 Jun 2018 15:05:40 -0700 (PDT)
X-Gm-Message-State: APt69E3bIMnfJ+EOa2Z261/LD2hMlLzlp9K6qIdZX4GAAFhcWaJ+WHtU hq0V/NWCzcOmoy/q3Rk3QijN++SZyI1+dgWrM84=
X-Google-Smtp-Source: ADUXVKKmVLIyFFGTmQ00RCFvVpkjkdBfCbZPy6ifRl62C39voY2wSzmF5QwiCEZwVBAM98yTT+jdNRvhB9HLju9P8ZQ=
X-Received: by 2002:a9d:2f2a:: with SMTP id h39-v6mr13356484otb.214.1529532340003; Wed, 20 Jun 2018 15:05:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 15:05:39 -0700 (PDT)
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 20 Jun 2018 18:05:39 -0400
X-Gmail-Original-Message-ID: <CAOdDvNpY4NpvSKW_D__jztDD_wkaRsJna9L+Br+hdnDnQ8w5SQ@mail.gmail.com>
Message-ID: <CAOdDvNpY4NpvSKW_D__jztDD_wkaRsJna9L+Br+hdnDnQ8w5SQ@mail.gmail.com>
To: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cc686c056f19ff3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Y1imMm9vJi2D5emVr3SfKkqMzqA>
Subject: [Doh] New Privacy Considerations Section Proposal
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2018 22:05:54 -0000
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.
- Re: [Doh] New Privacy Considerations Section Prop… Adam Roach
- Re: [Doh] New Privacy Considerations Section Prop… Adam Roach
- Re: [Doh] New Privacy Considerations Section Prop… Ted Hardie
- Re: [Doh] New Privacy Considerations Section Prop… Ted Hardie
- Re: [Doh] New Privacy Considerations Section Prop… Patrick McManus
- Re: [Doh] New Privacy Considerations Section Prop… nusenu
- Re: [Doh] New Privacy Considerations Section Prop… Patrick McManus
- Re: [Doh] New Privacy Considerations Section Prop… Sara Dickinson
- Re: [Doh] New Privacy Considerations Section Prop… Eric Rescorla
- Re: [Doh] New Privacy Considerations Section Prop… Patrick McManus
- Re: [Doh] New Privacy Considerations Section Prop… Sara Dickinson
- Re: [Doh] New Privacy Considerations Section Prop… Sara Dickinson
- Re: [Doh] New Privacy Considerations Section Prop… Patrick McManus
- Re: [Doh] New Privacy Considerations Section Prop… Patrick McManus
- Re: [Doh] New Privacy Considerations Section Prop… Howard Chu
- Re: [Doh] New Privacy Considerations Section Prop… nusenu
- Re: [Doh] New Privacy Considerations Section Prop… Howard Chu
- Re: [Doh] New Privacy Considerations Section Prop… Mateusz Jończyk
- Re: [Doh] New Privacy Considerations Section Prop… bert hubert
- Re: [Doh] New Privacy Considerations Section Prop… nusenu
- Re: [Doh] New Privacy Considerations Section Prop… nusenu
- Re: [Doh] New Privacy Considerations Section Prop… Sara Dickinson
- Re: [Doh] New Privacy Considerations Section Prop… Daniel Stenberg
- Re: [Doh] New Privacy Considerations Section Prop… Howard Chu
- Re: [Doh] New Privacy Considerations Section Prop… nusenu
- Re: [Doh] New Privacy Considerations Section Prop… Patrick McManus
- Re: [Doh] New Privacy Considerations Section Prop… nusenu
- Re: [Doh] New Privacy Considerations Section Prop… Hewitt, Rory
- Re: [Doh] New Privacy Considerations Section Prop… Adam Roach
- Re: [Doh] New Privacy Considerations Section Prop… Patrick McManus
- Re: [Doh] [Ext] New Privacy Considerations Sectio… Ted Hardie
- Re: [Doh] [Ext] New Privacy Considerations Sectio… Paul Hoffman
- Re: [Doh] New Privacy Considerations Section Prop… Ted Hardie
- [Doh] New Privacy Considerations Section Proposal Patrick McManus
- Re: [Doh] New Privacy Considerations Section Prop… Loganaden Velvindron