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

nalini elkins <nalini.elkins@e-dco.com> Wed, 13 March 2019 03:01 UTC

Return-Path: <nalini.elkins@e-dco.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 095D012705F for <doh@ietfa.amsl.com>; Tue, 12 Mar 2019 20:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-com.20150623.gappssmtp.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 ih20hDGuloCT for <doh@ietfa.amsl.com>; Tue, 12 Mar 2019 20:01:34 -0700 (PDT)
Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 DB56812DF71 for <doh@ietf.org>; Tue, 12 Mar 2019 20:01:33 -0700 (PDT)
Received: by mail-it1-x12d.google.com with SMTP id m137so565242ita.0 for <doh@ietf.org>; Tue, 12 Mar 2019 20:01:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PGWHMj19m/q97PLz87G24G01FEM3IGbwUF2F4ZyBVkQ=; b=Uo0VfLVFNcBLcKltRBk4VCVlOm1G9gDe9ch4nfpeL7IPjgtNnl9LmdeAy3jWCtq8vD Go3iwo358VqiTl5C6L7cyQGGNF6svDKARCl+XaduPFWYFGhWsz/Gz1fMj1qXQrtsJCuN 4LBToj8U/HEQ4jT57I4LGz6lc/l6E0MICIqkRkzYAbWhjnC8vZCkimtGYl/5PHS6rINV rqLrZU+hLQFQ8pP5NNcatFRK4qaezKyHnz9I2pKFYmPkF3LzdVFNCuMY9KGAYp+V3BT+ Itpz74z3Mzjs2uRVjhepnU1jlk8bR+kBIVl0VTmlHgUmyhB3Y4FK77cXwPCOXMcQtdgF Oegw==
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=PGWHMj19m/q97PLz87G24G01FEM3IGbwUF2F4ZyBVkQ=; b=WDHGeh64Bwqcu7u8vXDwQKz3670ZbvjB8WwGONbXWfZnGDBqSWjWyeO/YDAxT1YWvR rkyL1cuPE98ILF5hCn4xEzCeMkf83NVZEkV/Q20+TCA6HVoD0vUGe9swd+9a2uRNGVgt 0smqNnRSVs7rQHZdnKcfvbXI5nRrMmj+NjF80LP2vmKjbZqmr+/ETLFJ4KnkV93QV/Kr 15XgXm62+DbIzm+ccOnY4Mva8KVA3pYvvcc088BdjpU2qQPvQz+DEAFLQEDQnKbloR6x gIQHghL2ZXXDqcUYNIPZb1OyvRuPh3tqIJMstZtG2wyhgCJOfKJBn/2H+AP8xhvMy/s5 bilA==
X-Gm-Message-State: APjAAAVO6MVSyYOr2t9HBRssmtwx5TLFUq35T4Wou6qaISGYKyE2hyzF LcuyflQnadjDedRcRjHp9VVMQvNbrwDuLGJP4FtBAw==
X-Google-Smtp-Source: APXvYqxDptKRt/MtA/U356feNzvR5+6x2DJVIBE6H+W2+X5f5MwYi9aIzNjqmHGU0Yl1UXHjudNa/S8vz4m+Hy9vMnU=
X-Received: by 2002:a24:4755:: with SMTP id t82mr566947itb.96.1552446093028; Tue, 12 Mar 2019 20:01:33 -0700 (PDT)
MIME-Version: 1.0
References: <CADWWn7VrjCqgTVdOm3fMH7CFOAY=6899ABreYYK6dzbERU=UGw@mail.gmail.com>
In-Reply-To: <CADWWn7VrjCqgTVdOm3fMH7CFOAY=6899ABreYYK6dzbERU=UGw@mail.gmail.com>
From: nalini elkins <nalini.elkins@e-dco.com>
Date: Wed, 13 Mar 2019 08:31:24 +0530
Message-ID: <CAPsNn2WtZ1teu78fefpR0KkSwyLNwypgAe50Y53RmfA9DpOU8w@mail.gmail.com>
To: Kenji Baheux <kenjibaheux=40google.com@dmarc.ietf.org>
Cc: doh@ietf.org, "Ackermann, Michael" <mackermann@bcbsm.com>
Content-Type: multipart/alternative; boundary="000000000000e885d60583f10589"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/1RGSyNXflM5NisgUpC2Q7Lmffcw>
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 03:01:37 -0000

*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"? 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=
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