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

Kenji Baheux <kenjibaheux@google.com> Wed, 13 March 2019 04:46 UTC

Return-Path: <kenjibaheux@google.com>
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 19B6012D826 for <doh@ietfa.amsl.com>; Tue, 12 Mar 2019 21:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 Iwlctf4f0uk2 for <doh@ietfa.amsl.com>; Tue, 12 Mar 2019 21:46:13 -0700 (PDT)
Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE677127916 for <doh@ietf.org>; Tue, 12 Mar 2019 21:46:12 -0700 (PDT)
Received: by mail-lf1-x142.google.com with SMTP id g12so390219lfb.13 for <doh@ietf.org>; Tue, 12 Mar 2019 21:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pT/sHcG1P2fC0iPPuRYGn3NrvIyEHEbyVsBCI+JORvU=; b=FcvzVozIg8u2MVmWgm/kSgBmKcXpvbxjEJusJTnLegl91xE7njPvD/rBEk+UAMMVOr NTDNLZ+R76G680Jt+h5RXVrAmrNXO4u/rSX0yuhyJbKBgnkJLhgf42CC8nJJZmeiPk3o hs+/csHmG37UgDV56967WbI0WlQH4OgMDhahvckxGVT4QmmC/6BZFgA0674182lZzJdc FzmoK20NLWULVMsbKA9HyO2xY508kEfYGAZSP7XcK7Vin4+hM5pxbQEQ/4cnMOrNwMFn suKiopitT0YKUPQkxx8EPKMTQgf5Qch/eNbLvcbRuuInrszJjEYIVL47F00FeUlpatxB 6Deg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pT/sHcG1P2fC0iPPuRYGn3NrvIyEHEbyVsBCI+JORvU=; b=dswNIEdVdhlttz474P4SI1zsYQO5w6HxY+C80mFkRrOy8h3saFwEcjIrCkcbBWMglo jt4lp26H3Tuy1/9xOiOkS+ithhYtciYC6JD2Is1bJqUqKjzXXo5/OOZeJssGWCKbtIlL 6J+tGe0SpXCGJIlzSBim6QJljSQE7pbHDcz27IOKn35GV8Aa0G9nIFyUqAxZrKEYNFlD 3ZhsWddB0eeiXDZ0TlSjruZQ13h3Agdr8QaSXGQuUrED+l6LYsa1Qm/X7hNO4sT7dngL PB6rRr4TpLJHkigmfKriSMssszUYHVUG6rua9QCmHTRAi6Z83w8N6h2+XtmELZ/ku+lm j1vw==
X-Gm-Message-State: APjAAAVHUmTztYYapK+XuneJUzZb4/r3b/5joTtlsxx72ubomtjkSqTU B/OXCs8evZdE79p445KzlQ8t/mmmKWB8vjGn4ACb7g==
X-Google-Smtp-Source: APXvYqxYqSO/jvpSfriYweF9GxU6Di8P7WsCGZHQi04biOTNTDItDR/irotN52usMn5IAQ+7PHgyXdpE7WfEc2VGjXc=
X-Received: by 2002:a19:4b14:: with SMTP id y20mr8541728lfa.36.1552452370613; Tue, 12 Mar 2019 21:46:10 -0700 (PDT)
MIME-Version: 1.0
References: <CADWWn7VrjCqgTVdOm3fMH7CFOAY=6899ABreYYK6dzbERU=UGw@mail.gmail.com> <CAPsNn2WtZ1teu78fefpR0KkSwyLNwypgAe50Y53RmfA9DpOU8w@mail.gmail.com>
In-Reply-To: <CAPsNn2WtZ1teu78fefpR0KkSwyLNwypgAe50Y53RmfA9DpOU8w@mail.gmail.com>
From: Kenji Baheux <kenjibaheux@google.com>
Date: Wed, 13 Mar 2019 13:45:58 +0900
Message-ID: <CADWWn7U0_uuW8SLW8V+1rKxy9ZZZKSrgNc5iAEBkv3XjgDWT0w@mail.gmail.com>
To: nalini elkins <nalini.elkins@e-dco.com>
Cc: doh@ietf.org, "Ackermann, Michael" <mackermann@bcbsm.com>
Content-Type: multipart/alternative; boundary="0000000000001535f50583f27c64"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/xkScqsoxJFDE7NKro6qvvQWmSy4>
Subject: Re: [Doh] Concerns around deployment of DNS over HTTPS (DoH)
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: Wed, 13 Mar 2019 04:46:23 -0000

On Wed, Mar 13, 2019, 12:01 nalini elkins <nalini.elkins@e-dco.com> wrote:

> *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.
> >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
>
> But, I am not sure I understand:
> >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.

Would we get an alert / notification?
>

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


> Thanks,
> Nalini
>
> On Wed, Mar 13, 2019 at 8:03 AM Kenji Baheux <kenjibaheux=
> 40google.com@dmarc.ietf.org> wrote:
>
>> *(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
>> _______________________________________________
>> Doh mailing list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh
>>
>
>
> --
> Thanks,
> Nalini Elkins
> President
> Enterprise Data Center Operators
> www.e-dco.com
>
>