[dns-privacy] Adaptive DNS Privacy and Oblivious DoH

Tommy Pauly <tpauly@apple.com> Fri, 04 October 2019 17:34 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 23F60120143 for <dns-privacy@ietfa.amsl.com>; Fri, 4 Oct 2019 10:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Uazfs3gX4-Rm for <dns-privacy@ietfa.amsl.com>; Fri, 4 Oct 2019 10:34:16 -0700 (PDT)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE8A12008D for <dns-privacy@ietf.org>; Fri, 4 Oct 2019 10:34:16 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com []) by nwk-aaemail-lapp03.apple.com ( with SMTP id x94HWP5G015193; Fri, 4 Oct 2019 10:34:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : mime-version : subject : message-id : date : cc : to; s=20180706; bh=RVoLRwEO04L12iKkE8MyLFV7spHkRKO0nDdw87qX37s=; b=bwf0ZXcunKhffay5h2/57XCmfUokLr0NFYKMgAxE9BMAuAeWP+NZkoQgkCZ8y1aUWVot M8sXT/WEFWA4IdJ3guxb+Pt1rLaKi2sWNiOQmTDsr9d4xd4NoeWTteSE6lzsSLO8AI7G 04WFjhjnmfST/uOPvyAmp9yyje//7JCzCmzzhbxE3R5C1AxkZhVihiJtA08fDjY86ZgZ Me24g9OE8Nsy2cr8nPPjiH2PTExzffDtMV+feuZf42w3lhC1UscAIK4/ghw/Sd6Ea/M+ X+Fh1cz7EJ0VRhrf5+qxhuK+SgINaf2IBIMESx7KI5RfiAfl6rvHskfGvz3SGbc0K/TZ 5w==
Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com []) by nwk-aaemail-lapp03.apple.com with ESMTP id 2vaqrn2qsg-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 04 Oct 2019 10:34:13 -0700
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com []) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPS id <0PYV00N9H2503150@ma1-mtap-s01.corp.apple.com>; Fri, 04 Oct 2019 10:34:12 -0700 (PDT)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <0PYV0010023GU300@nwk-mmpp-sz12.apple.com>; Fri, 04 Oct 2019 10:34:12 -0700 (PDT)
X-Va-T-CD: 145619abd9e6a5d6fba35ed6f39071aa
X-Va-E-CD: a44ae7747de68d09aa461af923334c0f
X-Va-R-CD: a9738b1d21980fea75d874754059df9a
X-Va-CD: 0
X-Va-ID: 87808f72-47b6-4c07-8433-7e524f3a9a1c
X-V-T-CD: 145619abd9e6a5d6fba35ed6f39071aa
X-V-E-CD: a44ae7747de68d09aa461af923334c0f
X-V-R-CD: a9738b1d21980fea75d874754059df9a
X-V-CD: 0
X-V-ID: acb49f1c-d93d-4d2c-a5a5-e144f23d6882
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-04_10:,, signatures=0
Received: from [] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <0PYV00LWY24Z7E50@nwk-mmpp-sz12.apple.com>; Fri, 04 Oct 2019 10:34:11 -0700 (PDT)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_58B1808F-E2E0-4A33-9115-EA845ED4CBF3"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Message-id: <F835A0C6-19DA-4728-B0B0-59A4C2F4F5F5@apple.com>
Date: Fri, 04 Oct 2019 10:34:07 -0700
Cc: Chris Wood <cawood@apple.com>, Eric Kinnear <ekinnear@apple.com>, Patrick McManus <mcmanus@ducksong.com>
To: dns-privacy@ietf.org
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-04_10:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Sx7ydR138-FF7Dw71rrAGPfNjTY>
Subject: [dns-privacy] Adaptive DNS Privacy and Oblivious DoH
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Oct 2019 17:34:18 -0000

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”.

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).
	• 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); 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. 

Inspired by 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. 

Tommy, Chris, Eric, and Patrick