Subject: Re: [dns-privacy] Adaptive DNS Privacy and Oblivious DoH

From: Tommy Pauly <[email-masked]>
Date: Fri, 01 Nov 2019 15:40:51 -0700

Hello DNS Privacy,

We've posted new versions of our drafts on discovering designated DoH servers, and Oblivious DoH:

https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01
https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-01

We got a lot of good input via email and on the GitHub. Some of the main changes in these versions are:

- Don't reserve a SVCB SvcParamKey yet (https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/60)
- Change the Oblivious DoH proxying mechanism to specify the target in the HTTP path query (https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/64)
- Derive a nonce from client random values (https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/pull/74)

Open issues that are tagged with "DISCUSS" can be found here. Please chime in if you have opinions!
https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/labels/discuss

Thanks,
Tommy

Name:		draft-pauly-dprive-adaptive-dns-privacy
Revision:	01
Title:		Adaptive DNS: Improving Privacy of Name Resolution
Document date:	2019-11-01
Group:		Individual Submission
Pages:		25
URL:            https://www.ietf.org/internet-drafts/draft-pauly-dprive-adaptive-dns-privacy-01.txt
Status:         https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/
Htmlized:       https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pauly-dprive-adaptive-dns-privacy
Diff:           https://www.ietf.org/rfcdiff?url2=draft-pauly-dprive-adaptive-dns-privacy-01

Abstract:
  This document defines an architecture that allows clients to
  dynamically discover designated resolvers that offer encrypted DNS
  services, and use them in an adaptive way that improves privacy while
  co-existing with locally provisioned resolvers.  These resolvers can
  be used directly when looking up names for which they are designated.
  These resolvers also provide the ability to proxy encrypted queries,
  thus hiding the identity of the client requesting resolution.

Name:		draft-pauly-dprive-oblivious-doh
Revision:	01
Title:		Oblivious DNS Over HTTPS
Document date:	2019-11-01
Group:		Individual Submission
Pages:		14
URL:            https://www.ietf.org/internet-drafts/draft-pauly-dprive-oblivious-doh-01.txt
Status:         https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/
Htmlized:       https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pauly-dprive-oblivious-doh
Diff:           https://www.ietf.org/rfcdiff?url2=draft-pauly-dprive-oblivious-doh-01

Abstract:
  This document describes an extension to DNS Over HTTPS (DoH) that
  allows hiding client IP addresses via proxying encrypted DNS
  transactions.  This improves privacy of DNS operations by not
  allowing any one server entity to be aware of both the client IP
  address and the content of DNS queries and answers.

> On Oct 4, 2019, at 10:34 AM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hello DNS Privacy,
> 
> We’ve published a set of new drafts that define what we’re calling “Adaptive DNS Privacy”. This is an approach to using technologies like DoH to improve privacy of name resolution without breaking the functionality provided by local network resolvers. It also does not require placing trust in one or more fixed resolvers, but instead allows server deployments to dynamically indicate which resolvers are designated for their zones.
> 
> From the perspective of an operating system vendor (for myself, iOS and macOS), the goal is to use this approach to DNS privacy in the system stub resolver such that it can be safely and automatically used by all applications.
> 
> The first draft is “Adaptive DNS: Improving Privacy of Name Resolution”.
> https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy <https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy>
> 
> This covers the overall architecture for both clients and server deployments. This includes:
> 
> 	• A mechanism for clients to discover DoH resolvers that are “designated” for certain names or zones, using a DNSSEC-signed SVCB record (https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc <https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc>).
> 	• An algorithm for clients to select which resolver to use for a given name based on precedence (defining how VPNs, local network resolvers, designated cloud-based resolvers, and Oblivious DoH lookups coexist).
> 	• A mechanism for local networks to advertise their rules and capabilities using a provisioning domain (https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains <https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains>); this allows the advertisement of a locally-designated DoH server, a list of names or zones over which the local network claims authority, and an indication of filtering requirements.
> 
> The second draft is “Oblivious DNS Over HTTPS”, which we refer to as ODoH. 
> https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh <https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh>
> 
> Inspired by Oblivious DNS (https://tools.ietf.org/html/draft-annee-dprive-oblivious-dns <https://tools.ietf.org/html/draft-annee-dprive-oblivious-dns>), this draft adds an extension to DoH for encrypting queries such that a resolver cannot know both the client’s IP address and the content of the DNS query. In contrast to Oblivious DNS, ODoH uses HTTP proxying to unlink query sources and destinations. (ODoH also uses HPKE (https://tools.ietf.org/html/draft-irtf-cfrg-hpke) for query public key encryption.)
> 
> Please take a read through the documents and provide feedback. We’re eager to iterate on these goals with the community.
> 
> You can also provide feedback and input on the GitHub repo: https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy.
> 
> If you are interested in working on implementing any of these protocols, please reach out for interop testing, etc. 
> 
> Best,
> Tommy, Chris, Eric, and Patrick
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 2 Nov 2019 12:57:20 +0100

On Fri, Nov 01, 2019 at 03:40:51PM -0700,
 Tommy Pauly <tpauly=[email-masked]> wrote 

> We've posted new versions of our drafts on discovering designated DoH servers, and Oblivious DoH:

If you want to separate the knowledge of the source IP address and the
knowledge of the QNAME, I still don't understand what is the point of
Oblivious DoH when we can simply connect to the DoH resolver over
Tor. This really deserves an explanation in the draft.

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 04 Nov 2019 08:20:05 -0800

> On Nov 2, 2019, at 4:57 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

You're correct that using DoH over Tor would achieve some of the goals, at least as far as separating client IP addresses and
query contents! However, there are a couple reasons we're interested in having DoH servers directly support receiving Oblivious queries:

- Coming from the perspective of an operating system, we're trying to define a solution that can be a relatively lightweight extension
to standard protocols that can be enabled as a default mode for users when we need to improve privacy. Distributing public keys
through DNS, and adding a proxy + encryption step to DoH is more practical for this kind of deployment than using Tor. Tor is also
meant as a generic connection-level anonymity system, and thus seems overly complex for the purpose of proxying a request/response
protocol such as DNS.

- If you do DoH over Tor, the client is still doing an end-to-end TLS connection with the server (thus allowing for more fingerprinting
surface), and the DoH server can still track the patterns of resolution that a single client does within their TLS connection. In order
to mitigate the correlation of resolutions, a client could open a new connection for each query, but that gets expensive as well.
Encrypting at the DNS message level, per-query, within longer-lived connections between clients and proxies, and proxies and target
servers, decreases the ability to correlate more effectively with fewer round-trips.

Thanks,
Tommy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 5 Nov 2019 11:44:55 +0100

On Mon, Nov 04, 2019 at 08:20:05AM -0800,
 Tommy Pauly <[email-masked]> wrote 
 a message of 45 lines which said:

> However, there are a couple reasons we're interested in having DoH
> servers directly support receiving Oblivious queries:

Ok, but these reasons should be put in the draft (may be in an
appendix), to avoid repeated questions.

> Tor is also meant as a generic connection-level anonymity system,
> and thus seems overly complex for the purpose of proxying a
> request/response protocol such as DNS.

On the other hand, it has been well-examined, well-checked and
well-attacked so we know the trust we can put in it. A new
cryptography protocol is always risky.

There have been exactly the same discussion at the beginning of DPRIVE
about the encryption layer for DNS. The proponents of TLS (which won,
and gave RFC 7858) mentioned the fact that TLS was battle-hardened and
well studied, the adversaries preferred a more DNS-friendly protocol,
such as draft-wijngaards-dnsop-confidentialdns.