Internet DRAFT - draft-dickinson-doh-dohpe
draft-dickinson-doh-dohpe
Network Working Group S. Dickinson
Internet-Draft Sinodun IT
Intended status: Standards Track W. Toorop
Expires: January 19, 2019 NLnet Labs
July 18, 2018
DoHPE: DoH with Privacy Enhancements
draft-dickinson-doh-dohpe-00
Abstract
This document describes DoHPE (DoH with Privacy Enhancements) - a
privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https]
clients. The profile provides guidelines on the composition of DoH
messages, designed to minimize disclosure of identifying information.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 19, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Dickinson & Toorop Expires January 19, 2019 [Page 1]
Internet-Draft DoHPE: DoH with Privacy Enhancements July 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol specification . . . . . . . . . . . . . . . . . . . 4
3.1. Selection of DoH server . . . . . . . . . . . . . . . . . 4
3.2. HTTPS connections . . . . . . . . . . . . . . . . . . . . 4
3.3. HTTP version . . . . . . . . . . . . . . . . . . . . . . 5
3.4. HTTP method . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. HTTP headers . . . . . . . . . . . . . . . . . . . . . . 5
3.5.1. User agent . . . . . . . . . . . . . . . . . . . . . 5
3.5.2. Other headers . . . . . . . . . . . . . . . . . . . . 5
3.6. Client authentication . . . . . . . . . . . . . . . . . . 5
3.7. Other HTTP functionality . . . . . . . . . . . . . . . . 5
3.8. Countermeasures to Traffic Analysis . . . . . . . . . . . 5
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Implementations . . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The DoH protocol [I-D.ietf-doh-dns-over-https] is currently under
development with stated potential use cases of:
"... preventing on-path devices from interfering with DNS operations
and allowing web applications to access DNS information via existing
browser APIs in a safe way consistent with Cross Origin Resource
Sharing (CORS)."
Whilst DoH has clear benefits in terms of encryption, authentication,
traffic obfuscation and ease of implementation, it introduce new
privacy concerns when compared with DNS over UDP, TCP or TLS
(RFC7858) simply because it introduces a new transport layer (HTTPS)
that can contain client identifiers (e.g. user-agent, accept-
language) not present in any existing DNS transport.
The privacy considerations section of that draft state the following:
"The DoH protocol design allows applications to fully leverage the
HTTP ecosystem, including features that are not enumerated here.
Utilizing the full set of HTTP features enables DoH to be more than
an HTTP tunnel, but at the cost of opening up implementations to the
full set of privacy considerations of HTTP."
Dickinson & Toorop Expires January 19, 2019 [Page 2]
Internet-Draft DoHPE: DoH with Privacy Enhancements July 2018
In other words a design choice was made with DoH not to add
constraints to the protocol on privacy grounds; specific choices of
functionality verses privacy are left to the implementation.
In the absence of a common standard and with many possible use cases
for DoH, different application developers are likely to implement
this compromise in different ways. Monitoring entities could then
use the differences to identify not only the device but the software
originating the DNS queries. A similar problem exists for DHCP
clients which [RFC7844] attempts to address.
The proposed profile provides a common standard that minimizes
information disclosure, including the disclosure of implementation
identifiers. Whilst fingerprinting in the TLS layer is of course
also possible, minimising the additional differences introduced by
HTTPS attempts to provide a DoH profile that has parity with DNS-
over-TLS from a privacy/anonymity perspective.
One use case for this profile is a client wishing to use DoH to
leverage several of the key advantages including:
o Encryption and authentication of the connection to the server
o Obfuscation of DNS traffic by using HTTPS on port 443 (to
preventing on-path devices from interfering with DNS operations)
o Ability to optionally use either DNS-over-TLS or DoH servers
depending on availability, reachability and latency
but to:
o introduce the minimum possible privacy concerns compared to e.g.
DNS-over-TLS
o not 'stand-out' among a DoH client population
The cost of this decision is limitations on the HTTPS functionality
available to the client which for this use case is considered
acceptable. An example of such a client is a system stub resolver
that offers multiple transports for DNS or a Tor exit node.
One advantage of standardizing this approach is that users of DoHPE
clients will have clear privacy expectations which is not necessarily
the case with general DoH clients because the choice of balancing
functionality against privacy is implementation specific.
Whilst a simple model using HTTP CONNECT to set up RFC7858 sessions
would be an option given the privacy centric goal of this
Dickinson & Toorop Expires January 19, 2019 [Page 3]
Internet-Draft DoHPE: DoH with Privacy Enhancements July 2018
specification building on top of DoH has several advantages including
clients being able to take advantage of media-types defined in future
DoH specifications.
Two issues need to be taken into account when considering how
deployable this profile is:
1. Interoperability issues in the absence of certain headers might
be expected
2. Some HTTPS libraries add several headers by default and so
implementors will need to take care to override this behaviour
As with DoH, this document focuses on communication between DNS
clients (such as operating system stub resolvers) and recursive
resolvers.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC8174].
3. Protocol specification
The protocol specification for DoHPE is that of DoH
[I-D.ietf-doh-dns-over-https] with the guidelines described in the
following sections.
3.1. Selection of DoH server
In order that all connections from a given device appear as similar
as possible DoHPE clients SHOULD by default use a system wide setting
for the DoH server if one exists and can be discovered.
3.2. HTTPS connections
DoHPE clients SHOULD send queries over connections used solely for
DoHPE ('dedicated DoHPE connections') to avoid mixing with other
HTTPS traffic that might contain HTTPS messages with client
identifiers.
TODO: Consider if DoHPE clients SHOULD expose configuration options
for users to select if they are willing to fall back to using
existing connections for DoHPE queries if issues are encountered with
the use of dedicated DoHPE connections.
Dickinson & Toorop Expires January 19, 2019 [Page 4]
Internet-Draft DoHPE: DoH with Privacy Enhancements July 2018
3.3. HTTP version
In order that all DoH connections from a device appear as similar as
possible DoHPE clients MUST use HTTP/2 [RFC7540] or later.
3.4. HTTP method
TODO: Consider specifying that DoHPE clients SHOULD use either GET or
POST to increase similarity?
3.5. HTTP headers
This profile obviously requires clients to include all mandatory
headers as specified on [RFC7540] and other applicable
specifications. [I-D.ietf-doh-dns-over-https] also makes
recommendations about the "Accept" header which apply to this
profile.
3.5.1. User agent
DoHPE clients SHOULD omit the user-agent header. DoHPE clients MAY
set this header to 'DoHPE client' if interoperability issues are
encountered.
3.5.2. Other headers
DoHPE clients SHOULD omit all other headers.
TODO: Consider if DoHPE clients should expose configuration options
so users can choose to include specific headers if interoperability
issues are encountered. Note that such configuration could serve to
allow fingerprinting.
3.6. Client authentication
HTTP Cookies MUST NOT be sent by DoHPE clients.
3.7. Other HTTP functionality
TODO: What else should be considered here?
3.8. Countermeasures to Traffic Analysis
This section makes suggestions for measures that can reduce the
ability of attackers to infer information pertaining to encrypted
client queries by other means (e.g., via an analysis of encrypted
traffic size or via monitoring of the unencrypted traffic from a DNS
recursive resolver to an authoritative server).
Dickinson & Toorop Expires January 19, 2019 [Page 5]
Internet-Draft DoHPE: DoH with Privacy Enhancements July 2018
DoHPE clients and servers SHOULD implement the following relevant DNS
extensions:
o Extension Mechanisms for DNS (EDNS(0)) padding [RFC7830], which
allows encrypted queries and responses to hide their size, making
analysis of encrypted traffic harder.
Guidance on padding policies for EDNS(0) is provided in
[I-D.ietf-dprive-padding-policy].
DoHPE clients SHOULD implement the following relevant DNS extensions:
o Privacy election per [RFC7871] ("Client Subnet in DNS Queries").
If a DoHPE client does not include an edns-client-subnet EDNS0
option with SOURCE PREFIX-LENGTH set to 0 in a query, the DNS
server may potentially leak client address information to the
upstream authoritative DNS servers. A DoHPE client ought to be
able to inform the DNS resolver that it does not want any address
information leaked, and the DNS resolver should honor that
request.
4. IANA considerations
None
5. Implementations
TODO: Add details of the next release of Stubby that will support
DoHPE.
6. Acknowledgements
Thanks to Stephane Bortzmeyer, Ben Schwartz and many others for
initial discussions on this topic.
7. Changelog
draft-dickinson-doh-dohpe-00
o Initial commit
8. References
8.1. Normative References
Dickinson & Toorop Expires January 19, 2019 [Page 6]
Internet-Draft DoHPE: DoH with Privacy Enhancements July 2018
[I-D.ietf-doh-dns-over-https]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", draft-ietf-doh-dns-over-https-12 (work in
progress), June 2018.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, <https://www.rfc-
editor.org/info/rfc7540>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[I-D.ietf-dprive-padding-policy]
Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf-
dprive-padding-policy-05 (work in progress), April 2018.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016, <https://www.rfc-
editor.org/info/rfc7830>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016, <https://www.rfc-
editor.org/info/rfc7844>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016, <https://www.rfc-
editor.org/info/rfc7871>.
Authors' Addresses
Sara Dickinson
Sinodun IT
Magdalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom
Email: sara@sinodun.com
Dickinson & Toorop Expires January 19, 2019 [Page 7]
Internet-Draft DoHPE: DoH with Privacy Enhancements July 2018
Willem Toorop
NLnet Labs
Science Park 400
Amsterdam 1098 XH
The Netherlands
Email: willem@nlnetLabs.nl
Dickinson & Toorop Expires January 19, 2019 [Page 8]
