Re: [Add] New Version Notification for draft-schinazi-httpbis-doh-preference-hints-02.txt

[Andrew Campling <[e-mail]>]

Can I check with you both, for your respective I-Ds, for clarification:

  *   Is personal data shared and/or processed by resolvers determined mechanistically, as opposed to being determined by a setting from the user device?  If so, what options are there for the owner of that data to give their consent to it being shared in this way?
  *   Can the device owner set a universal policy that might disable or restrict the mechanisms that you are proposing?

In other words, what control, if any, does the user have over any of this?


Andrew

From: Tommy Pauly <[e-mail]>
Sent: 26 July 2020 21:44
To: Nick Sullivan <nick=[e-mail]>
Cc: ADD Mailing list <[e-mail]>; David Schinazi <[e-mail]>; Jesse Kipp <[e-mail]>
Subject: Re: [Add] New Version Notification for draft-schinazi-httpbis-doh-preference-hints-02.txt

Hi Nick,

I definitely like the optimizations that this mechanism is looking for—specifically, binding resolutions to a DoH server that is hosted by the same CDN that provides the desired web content. This not only allows for faster resolution (based on being near the authoritative) and faster connections (based on tailoring DNS answers for the client’s subnet) as you describe, but has some privacy benefits in limiting the number of parties involved in subsequent resolutions.

The specific mechanism does cause some concerns for me, however.

I know this is just a hint, but the weak relationship between this hint and the DNS may cause issues. The DoH preference hint is one-way only, and determined only by the entity that is generating HTTP headers for a given URL. This means that neither the operator of the DNS zone for the origin, nor the target DoH resolver, have any way to influence or validate this hint. It is possible that these are all the same entity (Google content in a google.com<http://google.com> zone pointing to 8.8.8.8), but that’s not guaranteed. Nothing stops any website from providing a hint to direct clients to whichever DoH server it wants, for as long as it wants. I have no problem with HTTPS content helping to confirm that the owner of the cert for a name agrees to using a specific DoH server (see https://www.ietf.org/id/draft-pauly-add-resolver-discovery-01.html#name-confirmation-of-designation) but the primary control over DNS routing should lie with the operator of the DNS zone in order to get the optimizations described in the document.

It also seems like it would be more optimal for this indication of DoH server to be expressed for a set of names (names within a zone, or all subdomains, etc), rather than just a single host name. The text limits any hint to only apply to one name, which is good because the hint could otherwise cause problems for an entire zone, but means that the benefit is limited. If every YouTube video has a unique hostname that is only resolved once, wouldn’t it be better to learn that I should use 8.8.8.8 for all YouTube names?

What would the client behavior for this header be if there is a redirect? For any content that uses redirects, I assume these hints must be ignored?

Best,
Tommy


On Jul 13, 2020, at 1:25 PM, Nick Sullivan <nick=[e-mail]<mailto:nick=[e-mail]>> wrote:

ADD Working Group,

This is to inform you of a new submission of the doh-preference-hints document. This document was originally intended for the HTTPbis working group, but we were directed to the ADD group as a more appropriate venue to discuss it. Our intention is to put this document up for consideration to be adopted as a working group item.

Nick, David, Jesse

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Mon, Jul 13, 2020 at 12:36 PM
Subject: New Version Notification for draft-schinazi-httpbis-doh-preference-hints-02.txt
To: Jesse Kipp <[e-mail]<mailto:[e-mail]>>, Nick Sullivan <[e-mail]<mailto:[e-mail]>>, David Schinazi <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-schinazi-httpbis-doh-preference-hints-02.txt
has been successfully submitted by David Schinazi and posted to the
IETF repository.

Name:           draft-schinazi-httpbis-doh-preference-hints
Revision:       02
Title:          DoH Preference Hints for HTTP
Document date:  2020-07-13
Group:          Individual Submission
Pages:          8
URL:            https://www.ietf.org/internet-drafts/draft-schinazi-httpbis-doh-preference-hints-02.txt
Status:         https://datatracker.ietf.org/doc/draft-schinazi-httpbis-doh-preference-hints/
Htmlized:       https://tools.ietf.org/html/draft-schinazi-httpbis-doh-preference-hints-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-schinazi-httpbis-doh-preference-hints
Diff:           https://www.ietf.org/rfcdiff?url2=draft-schinazi-httpbis-doh-preference-hints-02

Abstract:
   When using a publicly available DNS-over-HTTPS (DoH) server, some
   clients may suffer poor performance when the authoritative DNS server
   is located far from the DoH server.  For example, a publicly
   available DoH server provided by a Content Delivery Network (CDN)
   should be able to resolve names hosted by that CDN with good
   performance but might take longer to resolve names provided by other
   CDNs, or might provide suboptimal results if that CDN is using DNS-
   based load balancing and returns different address records depending
   or where the DNS query originated from.  This document attempts to
   lessen these issues by allowing the web server to indicate to the
   client which DoH server can best resolve its addresses.  This
   document defines an HTTP header field that enables web host operators
   to inform user agents of the preferred DoH servers to use for
   subsequent DNS lookups for the host's domain.

   Discussion of this work is encouraged to happen on the ADD IETF
   mailing list [e-mail]<mailto:[e-mail]> or on the GitHub repository which contains
   the draft: https://github.com/DavidSchinazi/draft-httpbis-doh-
   preference-hints.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

--
Add mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add