Re: [dns-privacy] DNS over HTTPS via HTTP proxies

Martin Thomson <mt@lowentropy.net> Mon, 19 July 2021 06:27 UTC

Return-Path: <mt@lowentropy.net>
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 E57983A24FC for <dns-privacy@ietfa.amsl.com>; Sun, 18 Jul 2021 23:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=lowentropy.net header.b=PQsreq/A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eShtQB0+
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 wk_9K7svlZAA for <dns-privacy@ietfa.amsl.com>; Sun, 18 Jul 2021 23:27:49 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408233A24FB for <dns-privacy@ietf.org>; Sun, 18 Jul 2021 23:27:44 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E15415C0088; Mon, 19 Jul 2021 02:27:41 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Mon, 19 Jul 2021 02:27:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=AfyFl2q5iZz0D8i1w7YMqPx5rRH2 q3rvgmrgWb3Pci8=; b=PQsreq/AW2DbeeaW0DVQeEb62NXv6mygdFHHmOMwgQpl qJ9x2MXyd3TlRcWvEFW9Zcar3reNWTqmfVIUiRd+2x9ry1OSuPNE1ytHsMrraiYC dF44pKXHkmuClEVHKJfV/CNfBBF23dpjQemcPJhUxzyr542FlxokCVwMo7nq6Bd/ JPYtvi0acHW9SGGp03em89+vqi03PojYIjFDzvB6R/+lRvA43VKgI++K3Qq13+Yl beU6go137sHT48OMfPZTTUQ9aPOg3uJL4li7TQORRyjmv/YxfZuVZ2vV8+EIteSc ukgNzm5uiJr7VEU1LIB2XSX7/hhW1gD0rTirsvzX/Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=AfyFl2 q5iZz0D8i1w7YMqPx5rRH2q3rvgmrgWb3Pci8=; b=eShtQB0+ZVUcX3YhzZQfmo eODlIbfzjefBnI8m4EWsKxUqPTytBXu7LBc39e9QTkhnBCkBP42rB6iZYYxkBoHF a+gHFENbm6FvDK5HjgK+5e2moouLPlPtZYrHEhz5mhhavBLVqDypsqXlJDTxeQpZ L3AlDN+XMKDOd84DGXd66odrS46I4+2ARXkdDNHT1sZbZTn7irrP/cQrpAmlp+wO +MBoVEmQWbP5iH0CTj5FRyFaEF6VemUJphvhLb4wu1tABHtXYWvKsXbL8JnFX9Rt 0aFH8T3qewtiLMH+FRS2L5AiTfs5Sn7sLBu32fX0SmjFQwLfEA5wf6UPLVhlQVuw ==
X-ME-Sender: <xms:XBv1YAdnvayJiKhh9Yr0VN6ARt4cvYTGYXAIr5nOyNiPeYRcIJhh2w> <xme:XBv1YCNEnwu6u_s6vFUc9jR7X8ep1IRDZMuCepLPoGrlI1OJOjYvy9XjyvzBbqA_B 5qu-65fWOxOuqxJ7jA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdelgddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepveeggefgueellefffeeifedthfelgeektddthfdtteejgfekgffh ieejieegtdeunecuffhomhgrihhnpegrrhigihhvrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidr nhgvth
X-ME-Proxy: <xmx:XBv1YBjNqyush7_SQkr0HVEOIgUXIXjH_v3piEdUhWpbtX5oMjfQRA> <xmx:XBv1YF9PbRlq8WA4raIe2FcI0jPL0aKStVuyI7t18QJ1aXncUHbC7g> <xmx:XBv1YMvpsdLzdLOfUxVz8szYUL9OU4S4wafna3nW7YT-VXP3tKgvjA> <xmx:XRv1YF64rHBLM45QO5XO8ii75cn5hP7NIOlEha8SqXeneCGTE-g7Dw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id CD8573C0E6C; Mon, 19 Jul 2021 02:27:40 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b
Mime-Version: 1.0
Message-Id: <7478cf1d-3db8-4994-8026-637643174fb7@www.fastmail.com>
In-Reply-To: <CAFWeb9+K7Dbx8JFK2c+4M0LwWyMRNH2Txkz3i-f_0LZZ5r9keQ@mail.gmail.com>
References: <20210719.130020.1116859977665651658.fujiwara@jprs.co.jp> <01550c55-4d4c-48a8-bf5f-c0263d7c4d10@www.fastmail.com> <CAFWeb9+K7Dbx8JFK2c+4M0LwWyMRNH2Txkz3i-f_0LZZ5r9keQ@mail.gmail.com>
Date: Mon, 19 Jul 2021 16:27:17 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Alec Muffett <alec.muffett@gmail.com>
Cc: dns-privacy@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/4UJzJN1CWULGmpBN65PjmcBer3I>
Subject: Re: [dns-privacy] DNS over HTTPS via HTTP proxies
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Addition of privacy to the DNS protocol <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, 19 Jul 2021 06:27:55 -0000

On Mon, Jul 19, 2021, at 15:53, Alec Muffett wrote:
> 
> Hi Martin! This is a not an attack, I intend this as a genuine 
> question: I would be interested to know what you feel constitutes 
> "acceptable performance" - because of the clear outcomes of my work was 
> that running DNS queries over Tor was of comparable latency to many 
> people's experience of running local "advert-filtering" stub revolvers 
> such as PiHole.
> 
> As such, I for one am no longer concerned about ever-lower latency, as 
> opposed to "good enough".
> 
> I would be really interested in what you considered "good enough"?

Based on your paper, it looks like you essentially open a connection to the DoH server and then use that for DNS queries.  To that end, you would drop that connection only when idle.  Otherwise you would get connection reuse.  (I don't know what you have for resumption, but if you are using TLS 1.3, that shouldn't hurt performance that much.) 

Given that most sites involve a bunch of DNS queries (or hundreds), if you are web browsing that means that any circuit setup and connection establishment costs are paid about most once for each page view.  You still pay some latency cost for bouncing around the TOR network, but your tests show that while it is large, it's not so bad that it makes the whole thing unusable.  Your paper shows a p50 of just over 400ms for most of the DoH servers compared to 1500ms for DoHoT.  

I was speculating about a different baseline, where you might create a new connection for every DNS query.  At that point, TOR could be as much as twice as slow again.

If you go to one connection for each query, which would be required to get equivalent privacy to OHTTP, that adds another round trip to each query.  That could make DoHoT jump to as much as double, depending on what sort of proportion of your queries need to go to authoritative servers.  3s per query, along with all the extra overheads for circuit and connection setup, is much less appealing.

Cloudflare's oblivious DoH results (https://arxiv.org/pdf/2011.10121.pdf) are consistent with yours, showing p50 at ~150ms for DoH, ~300ms for ODoH, and ~700ms for DoHoT.  That's ~2x for ODoH and >4x for DoHoT.  And time is not the only relevant metric.  That used persistent connections, so DoHoT has worse privacy than ODoH.  And it is far more expensive to terminate lots of connections if you were seeking the privacy gains of ODoH/OHTTP.

Paying an extra round trip on a per-query basis is still something you could make your own judgment about.  Speaking as a browser-maker, even the 4x slowdown that comes from TOR with connection reuse would give us pause if we were thinking of deploying this for a lot of users.

The overheads of OHTTP/ODoH are not trivial, but when performance is not so bad and privacy is better, it's a trade-off worth considering.  (We're in the process of setting up our own experiments, which will consider the effect on web browsing, because doubling DNS query time might sound bad, but DNS is still a relatively small component of overall load times.)

Cheers,
Martin

p.s., I am not aware of any studies on the effect of PiHole on performance, but I would be surprised if it were significantly worse than baseline.  If it is that much worse, that would be a noteworthy result.