Re: [Add] Mozilla's DoH resolver policy

Wes Hardaker <wjhns1@hardakers.net> Fri, 12 April 2019 21:48 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2FE1201C1 for <add@ietfa.amsl.com>; Fri, 12 Apr 2019 14:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 HPffB3tGP3QF for <add@ietfa.amsl.com>; Fri, 12 Apr 2019 14:48:26 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3C2120144 for <add@ietf.org>; Fri, 12 Apr 2019 14:48:25 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 268FF20B15; Fri, 12 Apr 2019 14:48:20 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Wes Hardaker <wjhns1@hardakers.net>, Peter Saint-Andre <stpeter@mozilla.com>, add@ietf.org
References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <b64761dc-dfab-e4e1-4bfb-82d607efa590@riseup.net> <alpine.LRH.2.21.1904101324530.9940@bofh.nohats.ca> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <af5f5c76-0095-65a0-39d1-d29d4bb0e906@mozilla.com> <ybl36mn8b54.fsf@w7.hardakers.net> <f9d0cd98-db0c-7f42-d351-d9a5002c4765@mozilla.com> <CA+9kkMAobw2giYO=8pbLVi4ms0Ru+nYwhV5DGxLCwaUdX6EQyQ@mail.gmail.com> <yblv9zj5591.fsf@w7.hardakers.net> <CA+9kkMBMehkz3NbytL+vfDh+SwhW9At_q7oBL8a7XSEiSSrNwA@mail.gmail.com>
Date: Fri, 12 Apr 2019 14:48:20 -0700
In-Reply-To: <CA+9kkMBMehkz3NbytL+vfDh+SwhW9At_q7oBL8a7XSEiSSrNwA@mail.gmail.com> (Ted Hardie's message of "Fri, 12 Apr 2019 13:51:17 -0700")
Message-ID: <yblr2a651zv.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/ZSWf8cqxhNLMN8UJojAGiNMgiPE>
Subject: Re: [Add] Mozilla's DoH resolver policy
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2019 21:48:28 -0000

Ted Hardie <ted.ietf@gmail.com> writes:

> On Fri, Apr 12, 2019 at 1:38 PM Wes Hardaker <wjhns1@hardakers.net> wrote:
> 
>     > What this should do is associate the clients with the lowest latency
>     > resolver.
>    
>     I wish we (collectively) could get over the notion that latency was the
>     only, or the most important metric out there at all times.
>     Happy-eyeballs approaches to problems can go too far.
> 
> The world of browsers cares a lot about latency, since it effects page load time and
> thus revenue.  I don't think it is going away as *a* metric, in other
> words.

Nor should it!  It's an important one!  I never tried to say otherwise.

> What else do you want to see optimized here?

Like most "triangle-like" choices, there is likely no perfect balance of
metrics you could pick from and each of us would likely pick different
solution points.

The three big ones that are coming back time and time again are:

1. latency
2. privacy
3. authenticity

Right now, most web-browsers (as you point out) are optimizing for (have
always been in a race for) latency.  Only recently is the desire privacy
actually becoming important enough that there is a desire to use a
slightly slower protocol like DOH to achieve privacy away from
unencypted traffic to access point resolvers/ISPs, and from the access
point resolvers/ISPs.  This, itself, is probably a good trend.

But then you bring in the discussion of DNSSEC and authenticity, which
is the only current way to ensure end-to-end data integrity and combine
this with Martin's statement of

> We don't believe that DNSSEC is essential to our primary goals, which
> are improving privacy of browsing activity.

Which clearly shows that between the above three, they're willing to
sacrifice some level of authenticity to achieve better latency and
privacy.  Note, though, that this choice isn't wrong.  It's a choice.  I
may choose a different one, as may others.  And I'm more than sure my
list above is incomplete from an ideological stand point; it just
happens to be the three biggest I could think of.

It would be interesting to put a "pick two" dialog box in front of a
billion users and see what was selected.  Then watch them as the
usability changed and see if when presented the same choice a month
later if they'd stick with their original choice.

-- 
Wes Hardaker
USC/ISI