Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

Richard Bennett <richard@bennett.com> Sat, 23 March 2019 02:48 UTC

Return-Path: <richard@bennett.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 F2C3D130DBE for <dnsop@ietfa.amsl.com>; Fri, 22 Mar 2019 19:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bennett-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 Vji5zIY0r-DB for <dnsop@ietfa.amsl.com>; Fri, 22 Mar 2019 19:48:30 -0700 (PDT)
Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 980AF12D4EC for <dnsop@ietf.org>; Fri, 22 Mar 2019 19:48:30 -0700 (PDT)
Received: by mail-io1-xd44.google.com with SMTP id v4so3343974ioj.5 for <dnsop@ietf.org>; Fri, 22 Mar 2019 19:48:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bennett-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=K1ifK5ajiiFiWizCE2U4rVrk8jIE47p4X09MIQr0JeU=; b=QcOaClGy2dvJEQ+DoSni2MFuDpvtNdNdgom6cgtTJo2MLy8947hx98QJ10ul1MTveT IsMIeY/kkBi7KM9keI6pT1fE2xZ/bg7gVf8xeOKPcmDPj7744yeXF6u1ytNOQmhnLWBr hXMmgFNPHV0PUhi12woihWXuIMDrIsHCj3W/iA70wyVGm6gnTHjmXRDKaeKZfg5rc1pn 3J2vqYvepSmyKUqwvLlk7ktExvPJbAv4Caz/AX5n2hKNn9p+pRylJfs8CoKb3ZGnwvIe F84DVxPJn+y4OVF53SiEOvZ1y1m54WTQLRcT5auVC0hcUcUrKOXgdD3iNsfXVb8RpjNC ehpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=K1ifK5ajiiFiWizCE2U4rVrk8jIE47p4X09MIQr0JeU=; b=sTJlLawgBrHM2oNOIMerYXIp3rFfCO9j7nfEQPOdZA1P9QQz+n5+XVh+WtUxybH3GR 1hiU33x73ppdIIpCklurIIDabtdUQ8O0ZNdk41txpTMC0IEnwEbgeejSwoaRdVEbH0Iq XHTEzzc44s8b0jUx1e1t3yCMmmO0SYjFUDiMh2P0sEcaAEoe0HE4IyxOxiqCv6TzFxjC PzNgs9ks73penVAfYznI9OqlsWDUoMSQjsd7x1PXIrnYH3DCw1nQ9sTmvgBmMQNGLiTE LCNPA2aeS0BRQzcl6PhKWUClpCnHYZaXJq6w1nQ8QbBTnVDKo74ZvRvso9r7ixGRUY1E RZdg==
X-Gm-Message-State: APjAAAWSjiVS2bzo+hiAYwh/3qABaoyn259ixPq3Shy3oQrimnVlsAUw ruGbIaDMX5AHuCFOrnlF3pFHyw==
X-Google-Smtp-Source: APXvYqxMyF6mK0Wjyqhpu7nGeLKqWysTfBmf/GXbvoudmJRjbFD8z4007u/gNqt+dPOCQpmJy3Dzhg==
X-Received: by 2002:a6b:3ec3:: with SMTP id l186mr8758235ioa.255.1553309309496; Fri, 22 Mar 2019 19:48:29 -0700 (PDT)
Received: from ?IPv6:2601:285:1:d1ab:49a0:b1c3:e34f:ae47? ([2601:285:1:d1ab:49a0:b1c3:e34f:ae47]) by smtp.gmail.com with ESMTPSA id j66sm2380214itb.38.2019.03.22.19.48.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 19:48:28 -0700 (PDT)
From: Richard Bennett <richard@bennett.com>
Message-Id: <4E034A1E-1282-4459-8B4E-3F6BE89A90C4@bennett.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9D37CE4D-E528-42FE-9C7B-780A60A6C4A9"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 22 Mar 2019 20:48:26 -0600
In-Reply-To: <CA+9_gVujw0MfF3Q3A6tGbL6QDjLLyt=8-Wd3vgbhBs9razs_bw@mail.gmail.com>
Cc: 神明達哉 <jinmei@wide.ad.jp>, Ted Hardie <ted.ietf@gmail.com>, DoH WG <doh@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>, Jared Mauch <jared@puck.nether.net>, dnsop <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>, Michael Sinatra <michael@brokendns.net>, Joe Abley <jabley@hopcount.ca>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: Puneet Sood <puneets=40google.com@dmarc.ietf.org>
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <3457266.o2ixm6i3xM@linux-9daj> <CA+9kkMDkKQtBDrXx9h8331_6zDtcChUTfqFe0W3JByxyB=4xLw@mail.gmail.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <a38cf205-b10e-e8e2-62cf-8e0377dfc1ef@brokendns.net> <4599B066-BA82-4EA8-92C1-F1BE1464A790@puck.nether.net> <b8c58757-3945-ea19-b018-8e59292abf30@cs.tcd.ie> <CAH1iCirBm0NKA2-zw--ZKd3gN1ZCmwZ7_ZOSyaTk+2SMmrtxKg@mail.gmail.com> <EA89EA1A-A1EA-4887-9294-4F68AB5C3211@puck.nether.net> <91A0BBD0-CB73-498E-B4E0-57C7E5ABE0B4@hopcount.ca> <CAJE_bqfEoy4Lbei27XNTbRSF9XHoAQ1gYPNerTXg9y6swp1a0w@mail.gmail.com> <CA+9_gVujw0MfF3Q3A6tGbL6QDjLLyt=8-Wd3vgbhBs9razs_bw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Xh1K_46n1XqglpR2qid1YkD5om8>
Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
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: Sat, 23 Mar 2019 02:48:35 -0000

I like it if you would kindly define “privacy” in the context of “a DNS resolver that protects our users’ privacy.” Does that mean hiding their lookups from ISPs who might want to enter the market for targeted ads while using them for your company’s own purposes, or just protecting user queries made over insecure public Wi-Fi networks from easy snooping? Because there are better ways to do the latter than with a system that opts users into a centralized resolver.

RB

> On Mar 22, 2019, at 4:08 PM, Puneet Sood <puneets=40google.com@dmarc.ietf.org> wrote:
> 
> Hello,
> 
> There has been much discussion in the IETF lists over the impact of
> using DNS-over-HTTPS (DoH) in a network. We would like to clarify the
> Google Public DNS position on this topic. The post I am replying to is
> particularly relevant since it makes some assumptions about the plans
> of the Google Public DNS service.
> 
> For future support of a RFC 8484 compliant service, we plan to do the following:
> * Serve RFC 8484 compliant DoH from the well known Google Public DNS
> anycast IP addresses (e.g. 8.8.8.8) on the standard HTTPS port 443.
> * Migrate our existing DoH services to the well known Google Public
> DNS anycast IP addresses, including the beta version (at
> https://dns.google.com/resolve) and IETF draft version (at
> https://dns.google.com/experimental).
> 
> The Google Public DNS anycast IP addresses are distinct from the IP
> addresses used to host web content for Google properties. This will
> allow operators to control access to the Google Public DNS DoH service
> on their networks without impeding access to other Google services.
> 
> For DoH implementers we want to ensure the same access to our
> implementation whether it is a Google product (like the Chrome
> browser) or a third-party product. To this end we aim to track IETF
> work on standardized ways to detect DoH support by the system-selected
> DNS resolver service (like
> https://tools.ietf.org/html/draft-ietf-doh-resolver-associated-doh-02
> or https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01).
> 
> As a core principle, Google Public DNS aims to provide a DNS resolver
> that respects our users’ privacy. Towards that goal, we aim to provide
> high quality implementations of various DNS transport mechanisms that
> our users can use to reach the service. This includes the traditional
> UDP and TCP transports as well as DNS-over-TLS and DNS-over-HTTPS that
> provide privacy for the user’s communication with a DNS resolver.
> 
> -Puneet Sood
> TL/Manager for the Google Public DNS team.
> 
> PS: I am attending IETF 104 and will be available for face-to-face discussion.
> 
> On Wed, Mar 20, 2019 at 2:40 PM 神明達哉 <jinmei@wide.ad.jp> wrote:
>> 
>> At Wed, 20 Mar 2019 12:38:05 +0100,
>> Joe Abley <jabley@hopcount.ca> wrote:
>> 
>>>> Often as an industry we may discuss various solutions that are great for oneself but don’t scale when looking at the big picture.
>>> 
>>> I think what we are seeing is the fundamental tension between privacy and control. You need to give up some privacy in order to make the control possible; you need to give up some control in order to afford privacy.
>> 
>>> Some in this thread want certainty that they are able to exercise control, e.g. for devices in their network.
>> 
>>> Some in this thread want certainty that they can obtain privacy, e.g. for for their device in any network.
>> 
>> [...]
>> 
>> Thank you for the nice, concise summary.  I think it's well-balanced
>> observation of where we are.  (I'm so glad I can finally see a
>> constructive post after seeing a common pattern of boring IETF
>> discussion, where people with different opinions just keep stating
>> their views without making any real progress:).
>> 
>>> Seems to me that there's a middle ground within sight here.
>>> 
>>> Standardise this privacy mechanism, and specify (with reasoning) that it should be implemented such that the existence of the channel (but not the content) can be identified as distinct from other traffic by third parties. Maybe specify use of a different port number, as was done with DoT.
>> 
>> I see that those who want to exercise control can live with this (or
>> at least using a different set of IP addresses for DoH servers than
>> those for other ordinary web services).  But I'm not so sure if that's
>> acceptable for the other group..  In that sense I'm curious whether
>> some big possible DoH providers are now willing to accept this middle
>> ground.  If my memory is correct the longer term plan at Google (and
>> maybe also Clouldflare?) is to provide DoH service on the same IP
>> addresses as those for other ordinary and popular web services (and on
>> port 443, of course), so that an intermediate operator cannot easily
>> block access to their DoH services.
>> 
>>> Those who choose to ignore that direction and create a covert channel using port 443 instead will do so. Nothing much we can do to stop that today (I guarantee it is already happening). The future is not really different.
>> 
>> True.  But I think giant providers tend to respect a community
>> consensus.  Niche or really malicious players may/will still ignore
>> it, but it would be very difficult for them to collocate their DoH
>> services with other important web services that can hardly be blocked,
>> so it shouldn't be a big problem for "those who want certainty of
>> control".  So if we can really agree on the above "middle ground" and
>> publish a BCP or something that describes the consensus, I guess we
>> can now really work on technical issues.  But I'm not sure if we can
>> reach that consensus.
>> 
>> --
>> JINMEI, Tatuya
>> _______________________________________________
>> Doh mailing list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh
> 
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

—
Richard Bennett
High Tech Forum <http://hightechforum.org/> Founder
Ethernet & Wi-Fi standards co-creator

Internet Policy Consultant