Re: [Doh] panel discussion on DoH/DoC

Joseph Lorenzo Hall <> Fri, 08 February 2019 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E181C1293B1 for <>; Fri, 8 Feb 2019 13:19:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bIi094B_h8Rd for <>; Fri, 8 Feb 2019 13:19:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D617412426A for <>; Fri, 8 Feb 2019 13:19:42 -0800 (PST)
Received: by with SMTP id s5so8231750oth.7 for <>; Fri, 08 Feb 2019 13:19:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jC33PuxJjmD7UwZOOTmy8COiP6sXmgaLHOpeE736xu8=; b=KzHEv3PZ6R/HIhvKZJQMokVeCradp05YerBiTr/CTOrJK/OXysJn26f8DRg7s0Ai2U 32C1DMw8Bjr+kJaskfJy3bKelWI4JocQ++uS66rrWBuSqzdBgF0g3ZDO3n8Knc+SEje8 9BdsLqOu5M96zJgyvaIOAxAEhPjm9ukYXSfhQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jC33PuxJjmD7UwZOOTmy8COiP6sXmgaLHOpeE736xu8=; b=F1jc5hV9ql152cgedbmjAt0+tp6JgXlwRqVb7UlssACoCD6EHhhfrr6nJYSrZRHTs9 6qeyN6mYbUQ1u2yM3WqE4VRwSSnJTEHqQ1QOQcnrGlI9LrLQqBt53Kf1mzamxv/EQsUV qgdVi5Md1WX0P9FABINesKGQB8xCvXgxfZgCymuyy2JfK8K7hSPU031u+q+ZSp4GGDNS ElZ7qYOeLcLD0u2A7CaMkCfhY0j67mw5HFgXt0USTDQEWzA8RtWpNAJMZz1DjL9GdzSq xKXkeKjKCCpO75z7JkGewBkleFrzbj+6rNJXQFhVoBODKvLC47M605HoJEDtHp3J6ltg NSyA==
X-Gm-Message-State: AHQUAua9hLq+Hl4VeCDAQUSHrr/ZOT1KyATOUX1G7rbwvsdyPqG7OLap zxcLA8SZmP3lXrGdex0cBdyoldBAqUjIrmsx5/JM4dZq
X-Google-Smtp-Source: AHgI3IbwxWKc9hCRH3a3LMl+YDdaYFEdrPPoVLwRQD2j8nsdtI5/+PwYW553Tcv5nsTtLIlvoqzFdprz/PE5+5imVR4=
X-Received: by 2002:a9d:a83:: with SMTP id 3mr15646820otq.88.1549660781892; Fri, 08 Feb 2019 13:19:41 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Joseph Lorenzo Hall <>
Date: Fri, 08 Feb 2019 16:19:31 -0500
Message-ID: <>
To: Shane Kerr <>
Content-Type: multipart/alternative; boundary="0000000000006d6bc705816884d2"
Archived-At: <>
Subject: Re: [Doh] panel discussion on DoH/DoC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Feb 2019 21:19:45 -0000

On Fri, Feb 8, 2019 at 3:26 AM Shane Kerr <> wrote:

> 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
> > which a very strong privacy policy and the next minute you are talking
> > to Google's 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 ( ,
> > ).
> 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?
Those are great points and I may have taken some liberty with the the
"multiplexing across many DOH providers" statement as I'm not really sure
what browsers want to do, it just seems like having one or a few options is
not ideal. Anyway, I recognize that the work I'm interested in is not
protocol work (as far as I can tell), so I'll stop bugging folks here!
best, Joe