Subject: Re: [dns-privacy] Concerns around deployment of DNS over HTTPS (DoH)

From: Kenji Baheux <[email-masked]>
Date: Wed, 13 Mar 2019 11:35:57 +0900

*(Sincere apologies about the multi-posting but the discussion seems to be
happening in different places...)*

Hi,

I'm involved with Chrome's DoH efforts.

I've noticed a few drafts listing concerns about certain types of
deployment for DoH. It appears that the key concerns are based on
assumptions about various browsers' plans. So, to address
misunderstandings, I'd like to share some background, and the high level
principles that guide our work on DoH in Chrome.

Our motivations in pursuing DoH in Chrome is to offer our users a better
user experience:

   -

   Stronger privacy and security.
   -

   Hopefully, some performance wins.

Principles and illustrative* examples:

   1.

   Provide our users with meaningful choice and control, e.g. allow
   end-users/admins to control and configure the feature, whether they want to
   use a custom DoH server, or just keep on using their regular DNS.
   2.

   Don't surprise our users, e.g. don't silently force a different provider.
   3.

   Continue to support admins for Education and Enterprise use cases, and
   parents for family use cases, e.g. prevent students/employees/kids from
   accessing unsafe/inappropriate websites.

*: not necessarily our actual concrete plans (still WIP for the most part,
subject to change due to unforeseen implementation hurdles, or informed by
feedback and discussion, etc.), only shared as a comprehension aid.

Tentative plans:

   -

   We are considering a first milestone where Chrome would do an automatic
   upgrade to DoH when a user’s existing resolver is capable of it.
   -

   There are some unanswered questions about how we will be doing that
   discovery, and would welcome input from the community. Perhaps, a good
   topic for IETF 104.
   -

   For Education and Enterprise use cases, we believe that a group policy
   to disable and/or configure the feature will be enough.
   -

   For family use cases, we believe that allowing users to keep using their
   existing solution or opting into a DoH compatible solution (if available)
   will be enough.
   -

   There are no plans to force any specific resolver without user consent /
   opt-in (see principle #2)

We believe that starting with an automatic upgrade approach should address
a lot of the concerns expressed in the various drafts, because it gives a
chance to existing players to play an active role in providing stronger
privacy and security to end-users.

PS: I won't be able to join IETF 104 to discuss this face to face, but I
will see if someone from our side can represent us.

-- 
Kenji BAHEUX
Product Manager - Chrome
Google Japan

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Mar 2019 23:49:14 -0400 (EDT)

> Our motivations in pursuing DoH in Chrome is to offer our users a better user experience:

>     We are considering a first milestone where Chrome would do an automatic upgrade to DoH when a user’s existing resolver is capable of it.

I'm confused how these two can both be done? You either prefer the local
ISP over Google DNS, or you prefer the faster of the two.

>     There are some unanswered questions about how we will be doing that discovery, and would welcome input from the community. Perhaps, a good topic for IETF 104.

that is interesting indeed. You doing some static name lookups to test
would just make those names be in cache and not a good probe. And
probing nonsense is something that you do too much of already and it
is causing too much root zone noise :P

> PS: I won't be able to join IETF 104 to discuss this face to face

I'm already envious :)

Paul

---

From: Kenji Baheux <[email-masked]>
Date: Wed, 13 Mar 2019 13:34:34 +0900

On Wed, Mar 13, 2019, 12:49 Paul Wouters <[email-masked]> wrote:

> >     We are considering a first milestone where Chrome would do an
> automatic upgrade to DoH when a user’s existing resolver is capable of it.
>

We would not change the underlying DNS provider. The only thing that would
change is how the DNS query is done: vanilla or DoH (if the existing DNS
provider is capable of it).

Discovery is an open question.

Until there is a better discovery story, we could have a list of
known-to-be-DoH-compatible DNS providers that we could check against and
map accordingly. Obviously, this doesn't scale but it seems reasonable for
the experimentation phase (gathering data, etc).

> is causing too much root zone noise :P

(^ ^;

---

From: nusenu <[email-masked]>
Date: Sun, 17 Mar 2019 13:22:00 +0000

> Discovery is an open question.

you ideas would certainly be appreciated for the current work on
DoH discovery mechanisms in the DoH WG:

https://datatracker.ietf.org/doc/draft-ietf-doh-resolver-associated-doh/
 
> the experimentation phase (gathering data, etc).

Are you planning to have a submission website for resolver operators
like you do have [1] for HSTS website operators?

[1] https://hstspreload.org/

Authentication/verification of the submission could take place via
the .well-known endpoint proposed in doh-resolver-associated-doh
or a similar mechanism.

kind regards,
nusenu

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu