Subject: Re: [Doh] Concerns around deployment of DNS over HTTPS (DoH)

From: Kenji Baheux <[email-masked]>
Date: Wed, 13 Mar 2019 11:32:23 +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: nalini elkins <[email-masked]>
Date: Wed, 13 Mar 2019 08:31:24 +0530

*Kenji,*

Thank you for your note.  I am happy to see the following:

*>*Don't surprise our users, e.g. don't silently force a different provider.
accessing
> unsafe/inappropriate websites

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.

What would be the nature of the "automatic upgrade"? That is, if there is
no "group policy" defined by an enterprise, what might be the default?
Would we get an alert / notification?

You may not have completely defined this, which I can understand. Thank you
again for sharing your plans.

Thanks,
Nalini

On Wed, Mar 13, 2019 at 8:03 AM Kenji Baheux <kenjibaheux=
[email-masked]> wrote:

>    parents for family use cases, e.g. prevent students/employees/kids
>    from accessing unsafe/inappropriate websites.
>
>    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.
>    -
>
>    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)
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com

---

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

On Wed, Mar 13, 2019, 12:01 nalini elkins <[email-masked]> wrote:

> >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.
>
> What would be the nature of the "automatic upgrade"?
>

With the usual "tentative" caveats:

To clarify, it would be something like "is this user's existing DNS known
to be capable of doing DoH? If yes then use this DNS provider's DoH
endpoint otherwise keep doing regular DNS queries ".

In other words, the DNS provider is kept as-is, we just try to upgrade to
the DoH flavor if it exists. Again, the discovery aspect needs to be
explored.

That is, if there is no "group policy" defined by an enterprise, what might
> be the default?

The default would be the "autoupgrade" explained above. I assume that
enterprises with specific needs are using their own DNS or DNS provider by
other companies. So, there shouldn't be any surprise.

As part of any Chrome releases, we communicate about any changes that might
impact Enterprises/Educations. So, no in-product notifications but
sufficient comms on our part.

> You may not have completely defined this, which I can understand. Thank
> you again for sharing your plans.
>

>> *(Sincere apologies about the multi-posting but the discussion seems to
>> be happening in different places...)*
>>
>>
>> Hi,
>>
>>    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:
>>
>>    -
>>
>>    For Education and Enterprise use cases, we believe that a group
>>    policy to disable and/or configure the feature 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.
>>