Reposting to the list what I shared with Richard Bennett earlier. The Google Public DNS privacy policy is at https://developers.google.com/speed/public-dns/privacy. Maybe I should have included a link to it in the earlier email. If you have comments on it, please share.
We are following https://tools.ietf.org/html/draft-ietf-dprive-bcp-op and have commented on an earlier version. -Puneet On Sat, Mar 23, 2019 at 3:48 AM Richard Bennett <rich...@bennett.com> wrote: > > 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....@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 神明達哉 <jin...@wide.ad.jp> wrote: > > > At Wed, 20 Mar 2019 12:38:05 +0100, > Joe Abley <jab...@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 > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > > _______________________________________________ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > > — > Richard Bennett > High Tech Forum Founder > Ethernet & Wi-Fi standards co-creator > > Internet Policy Consultant > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
