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

Tommy Pauly <tpauly@apple.com> Mon, 04 November 2019 16:20 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF73120130 for <dns-privacy@ietfa.amsl.com>; Mon, 4 Nov 2019 08:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNufWZ4zeBRq for <dns-privacy@ietfa.amsl.com>; Mon, 4 Nov 2019 08:20:10 -0800 (PST)
Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 3EC4D1200EF for <dns-privacy@ietf.org>; Mon, 4 Nov 2019 08:20:10 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id xA4GH7Gg037465; Mon, 4 Nov 2019 08:20:08 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=2m3t87kZ4mPBxP4nRXDjl2WNBhSNUBA0Wc3XHOURAVc=; b=gcB+nqdiJL9bg5uO8NNXmg4W1zsnl4pd6ivQI/qJxQvyuP/eaf0N8wU9+7qIGzCD0YGn 7L85rPbeNTWVWdshQHLP5diagngfABVZqMsdM9VTj+1shGQCIwXwA3ebv0Prfd3ZjeFJ +JpBhT0TnJ3TXN26iBSRWVth2pk0d/bJdhbXrrYC7lmGxSmp5rPEAICyCNEVgeRErfwH IYueBdivuRjby9wfaV+AIbJlvMvp5fk+v3oYImgUu3S3TiKzULRpAhUM+9+gnK2dQWGG qWpJuOZNygKufWvhKF5dt/rhjPNQuzL6Jla9AscLrPuGLuLSNm3NeGDT8B0cZADOJEza HQ==
Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2w16chh2d2-31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 04 Nov 2019 08:20:08 -0800
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q0G00GWYDDIZ910@ma1-mtap-s02.corp.apple.com>; Mon, 04 Nov 2019 08:20:07 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0G00800D8BZ000@nwk-mmpp-sz12.apple.com>; Mon, 04 Nov 2019 08:20:07 -0800 (PST)
X-Va-A:
X-Va-T-CD: f1d04214ca8681b6a9f9db7fe717fbc8
X-Va-E-CD: 9d1bea20dc3f20f2eff5978ff3b97e9f
X-Va-R-CD: 071c4b3d842a0acf642e52d3766deddf
X-Va-CD: 0
X-Va-ID: 317cdcb4-2d76-4a33-8534-622ba04f322c
X-V-A:
X-V-T-CD: f1d04214ca8681b6a9f9db7fe717fbc8
X-V-E-CD: 9d1bea20dc3f20f2eff5978ff3b97e9f
X-V-R-CD: 071c4b3d842a0acf642e52d3766deddf
X-V-CD: 0
X-V-ID: a22d76a5-f53a-42fa-9fc5-dbe0aec2b064
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-04_09:,, signatures=0
Received: from [17.234.86.19] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0G000CTDDIMU20@nwk-mmpp-sz12.apple.com>; Mon, 04 Nov 2019 08:20:07 -0800 (PST)
Sender: tpauly@apple.com
Content-type: text/plain; charset="us-ascii"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <20191102115720.GA18365@nic.fr>
Date: Mon, 04 Nov 2019 08:20:05 -0800
Cc: dns-privacy@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <F6A0B437-444E-49CB-A894-B6AA88DABBA0@apple.com>
References: <F835A0C6-19DA-4728-B0B0-59A4C2F4F5F5@apple.com> <A5D68E26-0281-41BC-8709-2DC229647C1A@apple.com> <20191102115720.GA18365@nic.fr>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-04_09:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/SngsoAwPqgvcQqdHRjzl1e8X3cA>
Subject: Re: [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: Mon, 04 Nov 2019 16:20:12 -0000


> On Nov 2, 2019, at 4:57 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> 
> On Fri, Nov 01, 2019 at 03:40:51PM -0700,
> Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote 
> a message of 393 lines which said:
> 
>> 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.

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