Re: [Doh] panel discussion on DoH/DoC

Shane Kerr <shane@time-travellers.org> Fri, 08 February 2019 08:26 UTC

Return-Path: <shane@time-travellers.org>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338F91288BD for <doh@ietfa.amsl.com>; Fri, 8 Feb 2019 00:26:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 RCjjs8wNjvxf for <doh@ietfa.amsl.com>; Fri, 8 Feb 2019 00:26:22 -0800 (PST)
Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E841286D8 for <doh@ietf.org>; Fri, 8 Feb 2019 00:26:21 -0800 (PST)
Received: from [2001:470:78c8:2:65fc:c318:cd2d:2bb1] by time-travellers.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1gs1VV-0000DC-JY for doh@ietf.org; Fri, 08 Feb 2019 08:27:33 +0000
To: doh@ietf.org
References: <20190207105106.GB1772@server.ds9a.nl> <C7C3BAF7-4BD4-4EE2-B3F2-1F8B49222980@fugue.com> <20190207130313.7g7hf4swaopnr75e@nic.fr> <FD7BFAFF-88B9-49BF-A652-3649ADCD53F9@fugue.com> <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com> <CABtrr-UfwtgmO80A9en0-4tyPKqRRdvwR3BVEQQv+ykrNt-=mg@mail.gmail.com>
From: Shane Kerr <shane@time-travellers.org>
Message-ID: <f9a06c5d-7af2-46b1-5929-490c22c602bb@time-travellers.org>
Date: Fri, 08 Feb 2019 09:26:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <CABtrr-UfwtgmO80A9en0-4tyPKqRRdvwR3BVEQQv+ykrNt-=mg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/OS172gfAwmEIu5pHbPQh15ov9-A>
Subject: Re: [Doh] panel discussion on DoH/DoC
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Feb 2019 08:26:24 -0000

Joe,

On 07/02/2019 16.33, Joseph Lorenzo Hall wrote:
> 3\. Software like browsers seem to want to have a list of DOH providers 
> that they can shuffle queries across in order to minimize the raw 
> quantity of queries any given DOH service sees from a given user. Right 
> now the big DOH services all have very very different privacy policies 
> and terms of service making such a list impossible as you'd be comparing 
> apples to oranges (e.g., one second you are talking to CF's 1.1.1.1 
> which a very strong privacy policy and the next minute you are talking 
> to Google's 8.8.8.8 which has a much less strong privacy policy). How 
> should application developers decide which kind of DOH service to build 
> into their offerings? (My own organization, CDT, is going to start an 
> effort in a few months to try and bring DOH providers together to set 
> some baseline "rules of the road" for these kinds of services and we'd 
> love to work with others thinking about the "wild west" of DOH.)
> 
> ----
> 
> I'm about to go on leave for a bit (18-Feb up to Prague) but would love 
> to help think through what might make sense here. We did a project last 
> year with VPN providers where we sought to clarify some "rules of the 
> road", so to speak, and ended up basically with a standard questionnaire 
> that providers answered ( https://cdt.org/issue/privacy-data/vpns/ , 
> https://cdt.org/insight/unedited-answers-signals-of-trustworthy-vpns/ ).

My feeling is that we should avoid any design or recommendations 
involving multiple upstreams.

My reasoning is that I think that trying to direct queries to multiple 
resolvers is going to run the risk of leaking more information than 
protecting it more.

Certainly a naive approach of just sending to a random server won't 
work, as that basically insures that every resolver operator will see 
every user action pretty quickly.

Trying to isolate to specific user actions might make sense - for 
example send all the queries based on visiting a give web site to a 
single resolver operator. That involves some knowledge about what a 
session or other meaningful grouping of privacy is.

Really I tend to think that in the end we'll re-visit the same problems 
that Tor and other obfuscating overlay networks have tried to address, 
and likely end up with similar solutions. I don't think the DNS 
community understands enough about this to start designing protocols at 
the IETF today. Maybe the web community does, as they are (usually) 
closer to the end user?

Cheers,

--
Shane