Subject: [Doh] panel discussion on DoH/DoC

From: bert hubert <[email-masked]>
Date: Thu, 7 Feb 2019 11:51:06 +0100

Hello everyone,

Last weekend at FOSDEM in Brussels there were three sessions on DNS Privacy,
Daniel Stenberg presented a keynote session “DNS over HTTPS – the good, the
bad and the ugly”, Vittorio Bertola discussed “The DoH Dilemma” while
Daniel, Stéphane Bortzmeyer and I formed a DNS Privacy Panel expertly
moderated by Jan-Piet Mens.

I wrote up what I learned on https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem/
and added some strongly worded conclusions on what I think of
"DoC-by-default".

So what is DoC? A lot of the animosity towards DoH is not actually directed at
DoH-the-protocol. The problem people have is with centralizing DNS on cloud
operators ("DoC").

For further discussions, if someone is venting on DoC but calling it DoH, we
can point out that they should not direct their anger at the poor DoH
protocol that can't help what people do with it.

Anyhow, this and much more can be found here:

https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem/

I hope this will be useful to you.

	Bert

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2019 07:55:46 -0500

> protocol that can't help what people do with it.

You could get into a really big fight with the HRPC folks about this statement.   DoH is perfectly designed to support the DoC use case, so doesn’t that mean that it effectively _is_ DoC?   It’s only _not_ DoC if there’s some way to prevent it from being DoC, and there isn’t.    So you might as well own it.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Feb 2019 14:03:13 +0100

On Thu, Feb 07, 2019 at 07:55:46AM -0500,
 Ted Lemon <[email-masked]> wrote 
 a message of 90 lines which said:

> You could get into a really big fight with the HRPC folks about this
> statement.

I'll ask them :-)

> DoH is perfectly designed to support the DoC use case, so doesn’t
> that mean that it effectively _is_ DoC?   It’s only _not_ DoC if
> there’s some way to prevent it from being DoC, and there isn’t.
> So you might as well own it.

The protocols are not innocent (they enable, they encourage, they
discourage) but they are not everything either. The dominance of Gmail
is not written in RFC 5321. DoH helps DoC ("helps", not "enables", DNS
over HTTPS was possible before), it does not decide DoC.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2019 08:08:58 -0500

> over HTTPS was possible before), it does not decide DoC.

Of course, but in fact it appears that one of the primary use cases for DoH is DoC.   I would have thought that the primary use case for DoH was to bypass network censorship, but when I suggested as much during the discussion on the draft, the response I got suggested that the authors really hadn’t had that in mind, and that indeed the use case they had had in mind was DNS resolution in HTTP sessions by Javascript clients.   Which is, pretty much, DoC, although not the use case that subsequently emerged, where browsers do it instead of using the local resolver.

There isn’t a criticism in here from me—it seems clear that DoC is something that exists or doesn’t based on what browser vendors do, and if we really care about it, the knob we have to turn is not not having the specification, but rather being selective in what browsers we use, or in how they are configured.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 7 Feb 2019 14:16:03 +0100

Ted,

> Of course, but in fact it appears that one of the primary use cases for DoH is DoC.   I would have thought that the primary use case for DoH was to bypass network censorship, but when I suggested a…

In theory one could send DoH queries to the server where you were 
getting an HTML page from, for any names that need resolution on that 
page. This would be a anti-DoC, indeed probably more decentralized than 
DNS itself is today.

If this model requires DNSSEC then it's not even that horrible, since 
web server operators would not be able to spoof or hijack DNS names.

Cheers,

--
Shane

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 7 Feb 2019 14:17:09 +0100 (CET)

> Il 7 febbraio 2019 alle 14.08 Ted Lemon <[email-masked]> ha scritto:
> 

Which of course depends on a) having a practical possibility of choice among many browsers having many different policies, and b) the browsers letting you configure your resolver freely.

Ciao,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 07 Feb 2019 14:22:53 +0100

Moin!

On 7 Feb 2019, at 14:16, Shane Kerr wrote:
> page. This would be a anti-DoC, indeed probably more decentralized 
> than DNS itself is today.
>
That model is horrible as it removes the possibility for DNS being a 
central control point and pretty much every enterprise applications out 
there (split horizon). Even with DNSSEC the results could be horrible as 
the CDN view from a server might be way different then from a client. 
Please don’t go there.

So long
-Ralf
—--
Ralf Weber

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2019 08:23:11 -0500

> Which of course depends on a) having a practical possibility of choice among many browsers having many different policies, and b) the browsers letting you configure your resolver freely.

Yes, it does.   UTSL?

> On Feb 7, 2019, at 8:16 AM, Shane Kerr <[email-masked]> wrote:

> In theory one could send DoH queries to the server where you were getting an HTML page from, for any names that need resolution on that page. This would be a anti-DoC, indeed probably more decentralized than DNS itself is today.
> 
> If this model requires DNSSEC then it's not even that horrible, since web server operators would not be able to spoof or hijack DNS names.

Except that perhaps I want to block, I don’t know, name resolution for various ad bug sites?   And then if the browser has a secure way past my block, suddenly I’m seeing ads again.   Whether you believe that ads are immoral or not, the fact is that this wrests control away from the end user.

---

From: Jim Reid <[email-masked]>
Date: Thu, 7 Feb 2019 13:51:54 +0000

> On 7 Feb 2019, at 13:08, Ted Lemon <[email-masked]> wrote:
> 

Up to a point Ted. However we’d be missing *a lot* if the focus was just on those configuration and control hooks for web browsers. Suppose OS vendors use DoH/DoC instead of (the equivalent of) libresolv. Then there are all the web-based apps on our smartphones. Can I trust my bank to pick the right trusted DoH/DoC provider? Or will these just use whatever Apple and google decide are the trusted defaults for iOS and Android? For some definition of trust..,

These sorts of meta-issues need to be documented and I think this WG might be the best place to do that.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2019 09:04:18 -0500

> These sorts of meta-issues need to be documented and I think this WG might be the best place to do that.

Doh?   Why not DPRIVE or DNSOP?

I agree that we should talk about this; not sure DoH is the right place to have the conversation though.

---

From: Jim Reid <[email-masked]>
Date: Thu, 7 Feb 2019 14:18:16 +0000

> On 7 Feb 2019, at 14:04, Ted Lemon <[email-masked]> wrote:
> 

DoH’s more likely to have web clue than those two WGs. 

The DoH WG’s explictly chartered to analyse "the security and privacy issues that
could arise from accessing DNS over HTTPS.” DPRIVE and DNSOP are not.

I agree with you that a discussion is needed about where best to consider these DoH/DoC trust issues. Perhaps that can get some agenda time in Prague?

---

From: Valentin Gosu <[email-masked]>
Date: Thu, 7 Feb 2019 15:20:32 +0100

On Thu, 7 Feb 2019 at 14:23, Ted Lemon <[email-masked]> wrote:

> On Feb 7, 2019, at 8:17 AM, Vittorio Bertola <
> [email-masked]> wrote:
>
> Which of course depends on a) having a practical possibility of choice
> among many browsers having many different policies, and b) the browsers
> letting you configure your resolver freely.
>
>
> Yes, it does.   UTSL?
>
> In theory one could send DoH queries to the server where you were getting
> an HTML page from, for any names that need resolution on that page. This
> would be a anti-DoC, indeed probably more decentralized than DNS itself is
> today.
>
> If this model requires DNSSEC then it's not even that horrible, since web
> server operators would not be able to spoof or hijack DNS names.
>
>
> Except that perhaps I want to block, I don’t know, name resolution for
> various ad bug sites?   And then if the browser has a secure way past my
> block, suddenly I’m seeing ads again.   Whether you believe that ads are
> immoral or not, the fact is that this wrests control away from the end user.
>

I think a very important point to make is that the existence of the DoH RFC
does not affect these sort of usecases at all. If an ad site wanted to load
ads without being constrained by DNS it could always hardcode IP addresses,
or use their own homegrown variety of DNS over HTTP(S) with the server of
their choice. The same is true for IoT devices. And even for browsers. If
Google wanted to perform all DNS resolutions using "frankenDNS over gQUIC",
there's hardly a way you can stop them.

Where having a DoH RFC is immensely helpful is that you now have lots
compatible server and client implementations. If you want to increase your
privacy in a coffee shop, just point your stub resolver to a DoH server -
be it Cloudflare, Google, or your own pi-hole that you have at home.
And when browsers implement DoH, it's easier to have a choice of DoH
servers, because implementations follow the same RFC.

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 7 Feb 2019 15:20:59 +0100 (CET)

> Il 7 febbraio 2019 alle 15.04 Ted Lemon <[email-masked]> ha scritto: 
> 
> On Feb 7, 2019, at 8:51 AM, Jim Reid < [email-masked]> wrote:

These are not "meta-issues", these are policy issues, the more so if we accept that there is no problem in the protocol itself, but rather in how it is being used. Moreover, these issues affect lots of non-technical stakeholders, and I suspect that they will soon pop up in several venues other than the IETF. This said, it would still be good to address them at the IETF as well, but this looks more like a job for DPRIVE, which has the word "policy" in its charter and "Document Best Current Practices for operating DNS Privacy services" as one of its objectives. (Though any place could be fine, and some may also argue that this is not really in the scope of any existing WG, since we are not just talking about DNS operators but also about DoH client implementers, though they could easily be the same entity.)

Ciao,
--

---

From: Jim Reid <[email-masked]>
Date: Thu, 7 Feb 2019 14:28:12 +0000

> On 7 Feb 2019, at 14:20, Vittorio Bertola <[email-masked]> wrote:
> 
> but this looks more like a job for DPRIVE, which has the word "policy" in its charter and "Document Best Current Practices for operating DNS Privacy services"

OTOH DoH didn’t exist when DPRIVE was created and what was meant then by DNS privacy is not quite the same as is meant today.

I think DoH is the better choice. Though there’s enough ambiguity/overlap between the WGs that the ADs might need to decide this.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 7 Feb 2019 10:33:01 -0500

Heya, I tried to think of a few good questions to the FOSDEM DNS privacy
panel [1] and included the following (forgive what may be a naive
question!):

----

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/ ).

best, Joe

[1]:
https://gist.github.com/jpmens/be639dfd798dba2d65fb1c98e209e3f8#gistcomment-2812589

On Thu, Feb 7, 2019 at 9:28 AM Jim Reid <[email-masked]> wrote:

>
>
> > On 7 Feb 2019, at 14:20, Vittorio Bertola <
> > but this looks more like a job for DPRIVE, which has the word "policy"
> in its charter and "Document Best Current Practices for operating DNS
> Privacy services"
>
> OTOH DoH didn’t exist when DPRIVE was created and what was meant then by
> DNS privacy is not quite the same as is meant today.
>
> I think DoH is the better choice. Though there’s enough ambiguity/overlap
> between the WGs that the ADs might need to decide this.
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

Don't miss out! CDT's Tech Prom is April 10, 2019, at The
Anthem. Please join us: https://cdt.org/annual-dinner/

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Feb 2019 15:36:24 +0000

On Feb 7, 2019, at 5:08 AM, Ted Lemon <[email-masked]> wrote:
> Of course, but in fact it appears that one of the primary use cases for DoH is DoC.  

That became a use case after the document was mostly finished.

> I would have thought that the primary use case for DoH was to bypass network censorship, but when I suggested as much during the discussion on the draft, the response I got suggested that the authors really hadn’t had that in mind, and that indeed the use case they had had in mind was DNS resolution in HTTP sessions by Javascript clients.  

You are probably misattributing, or misremembering, this discussion. It certainly wasn't me, and I'd be quite surprised if it was Patrick. Both of us were motivated to bypass network censorship. We *also* had a secondary use case, which was real DNS resolution by JavaScript applications (not "clients").

> Which is, pretty much, DoC,

Centralizing resolution on chosen providers has nothing to do with "cloud" unless the user choose a cloud provider. 

> although not the use case that subsequently emerged, where browsers do it instead of using the local resolver.

A browser vendor (Mozilla) does use a cloud provider as their default DoH server. That browser vendor has not explained why.

--Paul Hoffman

---

From: Adam Roach <[email-masked]>
Date: Thu, 7 Feb 2019 09:46:00 -0600

> A browser vendor (Mozilla) does use a cloud provider as their default DoH server. That browser vendor has not explained why.

The claim that Firefox has a cloud provider as its default DoH server 
isn't wrong on its face, but the implication that Firefox uses DoH by 
default is.

The claim that Mozilla has not explained why, however, is flatly false. 
There's been a lot of electronic ink spilled on the topic; including, 
notably: 
https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/

/a

---

From: Eliot Lear <[email-masked]>
Date: Thu, 7 Feb 2019 17:04:25 +0100

Hi Paul,

I agree with those who say that we are really in the realm of a policy and research discussion.  I want to focus on the latter below, just a bit.

> On 7 Feb 2019, at 16:36, Paul Hoffman <[email-masked]> wrote:
> 

What I am struggling with is what we think DoC is.  Is Google a could provider in this context or not?  If so, I think many of us were expecting that Google would offer DoH alongside 8.8.8.8 precisely to address the issue directly below.  And what I find interesting is that this seems to move the problem from one control/observation point to another.  And so this brings up a key research question that would be useful to answer, and perhaps those at FF and Chromium could answer it:

Is there a suitable user interface that will keep users from harming themselves with DoH?

That question itself begs the question, “How could a user harm him or herself with DoH”?   That is in itself a research question, but at least let me give one analogy to show how that might happen: consider the fly-by-night-shady-VPN-for-free providers that spy on all of your traffic, advertising at users who say, “we’ll get you around all DNS blockers.  Just click here to change your settings, and it will all Just Work.”

I think that’s what Joe and CDT are out to stop with the code of conduct (maybe I misunderstand), and it argues against a user knob.  It might be possible to provide users some sort of intelligent choice, and I would imagine that some of the players have put some serious thought into it.

> You are probably misattributing, or misremembering, this discussion. It certainly wasn't me, and I'd be quite surprised if it was Patrick. Both of us were motivated to bypass network censorship. We *also* had a secondary use case, which was real DNS resolution by JavaScript applications (not "clients”).

This matches my (perhaps faulty) recollection.

> Centralizing resolution on chosen providers has nothing to do with "cloud" unless the user choose a cloud provider.

I think one of us (perhaps me) is being pedantic about the definition of cloud.

> A browser vendor (Mozilla) does use a cloud provider as their default DoH server. That browser vendor has not explained why.

And what I would suggest is that we need a crisp problem statement, but I do not see a protocol issue here either (at least not yet).

I do see a potential protocol issue for enterprises, in as much as split-horizon is a thing, but I don’t know if that should be addressed inside DoH or through some other means such as an MDM, where configuration is tweaked to address it.  We’ve discussed that here before (long ago).  The protocol part I could see would be some nifty signal that indicates that split horizon is in effect in some way.  And it’s not strictly doh, but perhaps just a reserved RR of some form (being very speculative here).  But even that would be subject to abuse.

Eliot

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Feb 2019 16:06:44 +0000

On Feb 7, 2019, at 7:46 AM, Adam Roach <[email-masked]> wrote:
> The claim that Firefox has a cloud provider as its default DoH server isn't wrong on its face, but the implication that Firefox uses DoH by default is.

Sorry, I certainly didn't mean to imply that. The dialog where you can turn on DoH is completely clear that it is off by default.

> The claim that Mozilla has not explained why, however, is flatly false. There's been a lot of electronic ink spilled on the topic; including, notably: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/

We disagree that that article from six months ago explains why Cloudflare is still the default provider. 

--Paul Hoffman

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 7 Feb 2019 08:26:10 -0800

> On Feb 7, 2019, at 7:36, Paul Hoffman <[email-masked]> wrote:
> 

Another use case is to allow DNS server implementors to build on the significant investments being done in HTTP/QUIC/etc software and infrastructure.

Ask

---

From: Jim Reid <[email-masked]>
Date: Thu, 7 Feb 2019 16:28:39 +0000

> On 7 Feb 2019, at 16:04, Eliot Lear <[email-masked]> wrote:
> 

First, define harm :-)

---

From: Adam Roach <[email-masked]>
Date: Thu, 7 Feb 2019 10:41:07 -0600

> We disagree that that article from six months ago explains why Cloudflare is still the default provider.

I thought the following text in the article I cited was pretty clear: 
"We’ve chosen Cloudflare because they agreed to a very strong privacy 
agreement 
<https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/> 
that protects your data."

If you want a little more meat on that statement, I'll clarify that the 
agreement here isn't just some informal "put these words up on a 
webpage" kid of thing. There's a formal legal agreement in place between 
Mozilla and Cloudflare that ensures that Cloudflare is handling DoH 
queries with the standards of privacy that Mozilla demands as part of 
its core mission.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 7 Feb 2019 10:49:06 -0600

On 2/7/19 10:04 AM, Eliot Lear wrote:
> And so this brings up a key research question that would be useful to 
> answer, and perhaps those at FF and Chromium could answer it:
>

If there were a pat answer to this question, we would have gone to 
release with DoH last summer. The user experience around activating and 
configuring DoH remains, as you suggest, a research topic. The standard 
here is informed consent.

/a

---

From: bert hubert <[email-masked]>
Date: Thu, 7 Feb 2019 17:58:17 +0100

On Thu, Feb 07, 2019 at 10:49:06AM -0600, Adam Roach wrote:
> If there were a pat answer to this question, we would have gone to release
> with DoH last summer. The user experience around activating and configuring
> DoH remains, as you suggest, a research topic. The standard here is informed
> consent.

I just enabled DoH to Cloudflare with a single click in Firefox.

I did not get any warning or explanation what this would mean. It had a
prefilled entry for Cloudflare that I can't even change from the UI.

https://imgur.com/a/WQrRG5Z has a screenshot.

You might ponder if as a data controller you might have a duty to do more
than this, especially since it hardcodes Cloudflare. 

Because it does not look like informed consent to me.

	Bert

---

From: Eliot Lear <[email-masked]>
Date: Thu, 7 Feb 2019 18:00:16 +0100

Hi Adam,

> On 7 Feb 2019, at 17:49, Adam Roach <[email-masked]> wrote:
> 
>> And so this brings up a key research question that would be useful to answer, and perhaps those at FF and Chromium could answer it:
>> 
> If there were a pat answer to this question, we would have gone to release with DoH last summer. The user experience around activating and configuring DoH remains, as you suggest, a research topic. The standard here is informed consent.

Again, I haven’t been tracking this for quite some time, and so I didn’t want to presume that there wasn’t work done in this space.  Also, I’m quite certain you meant “meaningful consent” above.  Another question I wonder is whether there are times when DoH will be active and when it will not be active, again somewhat based on the enterprise use case, or whether it should either be enabled or disabled.  The issue is that if it can flip from one to the other, do you have to signal the user?  If you do, that becomes both real estate and signalling issues, the latter of which is subject to habituation.

Again, researchy stuff.  Which leads me to another question- if DoH has mostly finished in the IETF, maybe this becomes more of a topic for the IRTF?

Eliot

---

From: Adam Roach <[email-masked]>
Date: Thu, 7 Feb 2019 11:17:21 -0600

On 2/7/19 11:00 AM, Eliot Lear wrote:
> Again, researchy stuff.  Which leads me to another question- if DoH 
> has mostly finished in the IETF, maybe this becomes more of a topic 
> for the IRTF?

You're talking largely about user interface issues. I'd be extremely 
wary of throwing that into a forum populated primarily by engineers. 
I've learned enough about UI to appreciate that it's a wildly different 
discipline than engineering, and that there's not much hope of quickly 
training engineers on an excruciatingly complex topic that people have 
made multi-decade careers out of.

> prefilled entry for Cloudflare that I can't even change from the UI.

As above, I don't think the I{E,R}TF is the correct forum to debate 
specific UI decisions.

/a

---

From: Shane Kerr <[email-masked]>
Date: Fri, 8 Feb 2019 09:26:18 +0100

Joe,

On 07/02/2019 16.33, Joseph Lorenzo Hall wrote:
> 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/ , 

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

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 8 Feb 2019 16:19:31 -0500

> the IETF today. Maybe the web community does, as they are (usually)
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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Feb 2019 10:51:27 +1100

> protocol work (as far as I can tell), so I'll stop bugging folks here!

I don't think that this is entirely crazy.  I agree with Shane that trying to load balance between servers or randomly route to servers is likely to be worse than just picking one, but one option we've considered is picking one server randomly and using that consistently thereafter.  (Cue all the second-order questions regarding how to use that for tracking, etc...)

There is also talk of finding ways to route requests to servers that might own the same name, but that's far more risky.  In other words, this is not a decided matter because it is so clearly not simple.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 10 Feb 2019 19:10:53 -0500

Also, what do you mean exactly by "picking one server"?  The back end state 
surely (!?) won't be shared and there's no reason to suppose names or 
numbers get you to "the same" thing. So ...?

A
--
Andrew Sullivan
Please excuse my clumbsy thums.

On February 10, 2019 18:51:37 Martin Thomson <[email-masked]> wrote:

> I don't think that this is entirely crazy.  I agree with Shane that trying 
> to load balance between servers or randomly route to servers is likely to 
> be worse than just picking one, but one option we've considered is picking 
> one server randomly and using that consistently thereafter.  (Cue all the 
> second-order questions regarding how to use that for tracking, etc...)
>
> There is also talk of finding ways to route requests to servers that might 
> own the same name, but that's far more risky.  In other words, this is not 
> a decided matter because it is so clearly not simple.
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 10 Feb 2019 16:16:10 -0800

> numbers get you to "the same" thing. So ...?

The general idea would be to have a list of DoH servers (operators, not
machines) and then to randomly select one for each client. We haven't
decided to do this, so also haven't decided on how we'd implement it :)

-Ekr

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 10 Feb 2019 19:22:55 -0500

Ah, "operators" was the bit I'd missed. I'm not too sure I feel my heart 
soar over the idea of entrenching by application various vendor 
preferences, but I cheerfully concede that it's already reality anyway.

A
-- 
Andrew Sullivan
Please excuse my clumbsy thums.
On February 10, 2019 19:16:58 Eric Rescorla <[email-masked]> wrote:
> n Sun, Feb 10, 2019 at 4:11 PM Andrew Sullivan <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Feb 2019 11:40:55 +0000

Hiya,

> decided to do this, so also haven't decided on how we'd implement it :)

I agree that picking one like that is no worse and likely better than
round robin or similar, when considering how the DoH servers can affect
the browser user's privacy in "normal" scenarios. I'd guess that the
censorship scenario might call for something else though, esp if the
selected DoH server becomes unresponsive. Be interested if you've
thoughts on that. (Not sure myself what browser behaviours might be
best in such failure cases.)

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 11 Feb 2019 13:11:29 +0100

> On 11 Feb 2019, at 12:40, Stephen Farrell <[email-masked]> wrote:
> 
> Signed PGP part
> 
> Hiya,
> 
> the browser user's privacy in "normal" scenarios.

If you pick more than one and your information then subsequently leaks, how do you establish who leaked it?  One could keep a log, but then one has to protect the log.  One could devise some interesting hash-based selection algorithm, but the inputs would have to remain stable and the algorithm somehow accessible.

Sounds messy.

Eliot

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 11 Feb 2019 14:20:53 +0100 (CET)

> Il 11 febbraio 2019 alle 12.40 Stephen Farrell <[email-masked]> ha scritto:
> 
> 
> Hiya,
>> The general idea would be to have a list of DoH servers (operators, not machines) and then to randomly select one for each client. We haven't decided to do this, so also haven't decided on how we'd implement it :)
>
> I agree that picking one like that is no worse and likely better than round robin or similar, when considering how the DoH servers can affectthe browser user's privacy in "normal" scenarios. I'd guess that the censorship scenario might call for something else though, esp if the selected DoH server becomes unresponsive. Be interested if you've thoughts on that. (Not sure myself what browser behaviours might be best in such failure cases.)

Sooner or later, this will have to be addressed as a much broader architectural issue: the original assumption that all DNS resolvers give the same reply to all DNS queries everywhere to everyone, so it doesn't really matter which one you use, has been false for quite some time already, due to several use cases of which only a small minority pertains to censorship. Should we get back to the original principle - as a centralized/randomized DoH server set would possibly imply - or should we find ways to make localized DNS policies exist and work well?

Ciao,
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Feb 2019 09:18:24 -0800

> best in such failure cases.)

Well, as I said, we haven't really sorted this out. But it's also kind of
out of scope for this WG.

-Ekr

---

From: Jim Reid <[email-masked]>
Date: Mon, 11 Feb 2019 17:30:01 +0000

On 11 Feb 2019, at 17:18, Eric Rescorla <[email-masked]> wrote:
> 
>> On Mon, Feb 11, 2019 at 3:40 AM Stephen Farrell <[email-masked]> wrote:
>> 
> Well, as I said, we haven't really sorted this out. But it's also kind of out of scope for this WG.

Hmmm. Wouldn't the WG’s charter commitments on privacy and security apply to this topic?

Picking your favourite DoH service/server would probably be out of scope for the WG. However I think the privacy and security considerations that should be part of that selection decision would be in scope for the WG.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Feb 2019 09:35:46 -0800

On Mon, Feb 11, 2019 at 9:30 AM Jim Reid <[email-masked]> wrote:

> Picking your favourite DoH service/server would probably be out of scope
> for the WG. However I think the privacy and security considerations that
> should be part of that selection decision would be in scope for the WG.
>

Well, the WG was chartered to design this protocol and "analyze the
security and privacy issues". I think the main spec has done that.

Resolver selection seems pretty out of scope for that charter.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Feb 2019 22:40:52 +0000

> out of scope for this WG.

Sure. I wasn't implying anything about scope, I was just interested
in the problem as it seems relevant for people on this list. "Haven't
got there yet" is a perfectly good answer.

Cheers,
S.