Re: [DNSOP] Concerns around deployment of DNS over HTTPS (DoH)
Kenji Baheux <kenjibaheux@google.com> Wed, 13 March 2019 02:33 UTC
Return-Path: <kenjibaheux@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35304127994 for <dnsop@ietfa.amsl.com>; Tue, 12 Mar 2019 19:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
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: 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 53DERyAR7FPs for <dnsop@ietfa.amsl.com>; Tue, 12 Mar 2019 19:33:28 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 8C450129284 for <dnsop@ietf.org>; Tue, 12 Mar 2019 19:33:28 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id v10so255469qtp.8 for <dnsop@ietf.org>; Tue, 12 Mar 2019 19:33:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=X/wwV/iYpwkt0H4k+HdhfSpsc15g411r08cmSeaj97k=; b=IEtm4bzvFahnfwDpTkI4AXZ8SlccQHSTvsnLNIR3PRln/6L7fzVRqnb9uhg/2ofVjz f2Adjw+ubLP+vOGTsev1MFQ644bWbmvBkWEvT4bG3JQwkVmBoX9TW/H62KNToA//iML8 74m3DbtBvCEZRCgrY3nhCgPi9Fe35DAw/vw00LCVb0QdGj5bB5JzO6/Qx20Ii2yJ+Y3Z 9XfRQPh3UBPAHvRaYYmiJOIeVvOqaRcE6nOEH40VTdoppdJQhNikcYw19j9WYcqrnsRY 2Rp3VWvopwMXsTsbWhtzbkN8v7x0gmGeK3zADuGsMecHsYkPJy9sT2F5rvlXoAW7sYj2 NblA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=X/wwV/iYpwkt0H4k+HdhfSpsc15g411r08cmSeaj97k=; b=Wtsl7GU8uJPxRKLPSyeTZ5vZCys05RYZLorr+8C64VbNWuhmwiJO8FUlcupapz5LJT McW3BZ6t4YjN3xer8M70jJGCga0uprszGAXSM6JFaUd1djSTjEmafd9xIIJlhy9ySYxE rBTn3J2bF71H9y6xSQJw2AGKh2/ZlEcnAAu7DdaiRU9awTP+HujtBPk90PKELWyQjqwZ MNzsorI3qbXMZkdoY2veYe//8ijqIMNVmBNP99x+x5PZ5UG2TQwXrcFZwuykbHmVdSZ7 2qMbV+XVXJzCrCu3FXY5U3+zco/YiWfH6LFfccFar/EnUOIPkm6VJz/ES1rJZPp8GZxX aLdQ==
X-Gm-Message-State: APjAAAV77raatSwjQ3eVejQ6SPXr8YSNDGnCFyIy6JbE5eItFXSvoalE 54NEA6O5DeEyk8VX0HQhsuaJBG9CPxlauuSclV3bous2KOHtdg==
X-Google-Smtp-Source: APXvYqyyTT3FwRTAawH3OSn6XJRH+mP5PgYY36P7vLFfuD+eBe+koFc6q6g+pfpOPjt7UZCZQ99lE5FCSsVFoqAZO2M=
X-Received: by 2002:ac8:1bba:: with SMTP id z55mr8602423qtj.354.1552444407183; Tue, 12 Mar 2019 19:33:27 -0700 (PDT)
MIME-Version: 1.0
From: Kenji Baheux <kenjibaheux@google.com>
Date: Wed, 13 Mar 2019 11:33:14 +0900
Message-ID: <CADWWn7UZj3oAfqpcpnAenGDpZHatrvQ=97OxAWX8c3881oevhA@mail.gmail.com>
To: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006ce4cc0583f0a14c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dCuB-32Tz5YKCWsrJZ42SXmDs40>
Subject: Re: [DNSOP] Concerns around deployment of DNS over HTTPS (DoH)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2019 02:33:32 -0000
*(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 -- Kenji BAHEUX Product Manager - Chrome Google Japan
- Re: [DNSOP] Concerns around deployment of DNS ove… Kenji Baheux
- Re: [DNSOP] Concerns around deployment of DNS ove… Paul Vixie
- Re: [DNSOP] Concerns around deployment of DNS ove… Kenji Baheux
- Re: [DNSOP] Concerns around deployment of DNS ove… Erik Kline
- Re: [DNSOP] Concerns around deployment of DNS ove… nusenu
- Re: [DNSOP] Concerns around deployment of DNS ove… Paul Vixie
- Re: [DNSOP] Concerns around deployment of DNS ove… Paul Vixie
- Re: [DNSOP] Concerns around deployment of DNS ove… Erik Kline
- Re: [DNSOP] Concerns around deployment of DNS ove… Wes Hardaker
- Re: [DNSOP] Concerns around deployment of DNS ove… Paul Vixie
- Re: [DNSOP] Concerns around deployment of DNS ove… Olli Vanhoja
- Re: [DNSOP] Concerns around deployment of DNS ove… nusenu
- Re: [DNSOP] Concerns around deployment of DNS ove… Kenji Baheux
- Re: [DNSOP] Concerns around deployment of DNS ove… Brian Dickson
- Re: [DNSOP] Concerns around deployment of DNS ove… Tony Finch