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

Kenji Baheux <> Wed, 13 March 2019 02:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DA99127994 for <>; Tue, 12 Mar 2019 19:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GwajeHvkVYno for <>; Tue, 12 Mar 2019 19:32:37 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1DED128BCC for <>; Tue, 12 Mar 2019 19:32:36 -0700 (PDT)
Received: by with SMTP id u2so290370lfd.4 for <>; Tue, 12 Mar 2019 19:32:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ee99X5buP/qCX6ZOv7ytxmKIMNM6QQgOJ+AJRuHeOmM=; b=KgDkCmFsrRym09MR3cCnPqfa4HbRkj79RyCcw1ujXUrrQdaWnvDrbvaLKSu43EOEpe ccU/8gMc3DChMNP5PU0+tP+5DAHXvdhszgql8Jg+6WLmJ8Bvh3gmggbeZD9LwWyJ1+6P 7PZ9nIWsJ2YBvo8BjizzmGHWccCc5Fv24vJw5OsqtihBQr/i6fzHGOxxgCZx8y25jfnX h2vADqxIX9k3Z071hCvDJyX0Uk1szKZQaO0utT2GnA67Ag8Xk2etxlU6QOdN+XCjvRN3 49yju3feKybKnI/tmZrhGjYuMGmW8QPXhrbGhZmj131LPc+PzriZGAKchhWDrojjOhC2 Kf1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ee99X5buP/qCX6ZOv7ytxmKIMNM6QQgOJ+AJRuHeOmM=; b=fTwTgvVwzAa589CklE+Rzz56n010VhCW7bjQF2gJHedaSj+jBZy0PkGxQ9fIUQvdgg 8L7dLsMKibuG7GWSlcQf9aOsfXctRnoq2PNyqaG5fO14htABvQlFHTwnLr7VpIbAK4PA yrMo/g1a9F30uApeNQ/AqXlGC/i2Z0y4T9e+EvXjFLKv97xq1gKQb1pMXCnIoLE5Nmnp geIFwr8vdg/GzPKcddOg7hQ/vIhCKpNfeb45d8eFmCcUm/kOHU1Wy+4oMaAWMQkvCvi3 QfukFAVqypvYxX8QTtjelsKJHX34XP6DOdbDjFxJNWApoPTxqgs5PaG/VHp44lXGYmnL e8aQ==
X-Gm-Message-State: APjAAAVwVKRu92BDWpghWJG8JCdfnV3dwPKV5gF6A+OD4LrAuwn2So5D 8GNgx84D0NX8aEVwVN9v/uV3UdTIe83BuNim5VAvnqV+zdiJtw==
X-Google-Smtp-Source: APXvYqyyGk9WxqKcQ88aC5W/W8ASdCm4eFqZ7omhNyxOqioe5BsSH3fVTOC79gf/YYwrTWvC7Bzh8QtjA1lVZoUDy/E=
X-Received: by 2002:a19:7412:: with SMTP id v18mr6654954lfe.116.1552444354296; Tue, 12 Mar 2019 19:32:34 -0700 (PDT)
MIME-Version: 1.0
From: Kenji Baheux <>
Date: Wed, 13 Mar 2019 11:32:23 +0900
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000045e5080583f09e78"
Archived-At: <>
Subject: Re: [Doh] Concerns around deployment of DNS over HTTPS (DoH)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Mar 2019 02:32:43 -0000

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


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:


   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.

   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.

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

Product Manager - Chrome
Google Japan