Re: [Add] Mozilla's DoH resolver policy

Paul Wouters <paul@nohats.ca> Thu, 11 April 2019 11:36 UTC

Return-Path: <paul@nohats.ca>
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 708261201B1 for <add@ietfa.amsl.com>; Thu, 11 Apr 2019 04:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 3wKLcT3kuP7R for <add@ietfa.amsl.com>; Thu, 11 Apr 2019 04:36:49 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5816E12011D for <add@ietf.org>; Thu, 11 Apr 2019 04:36:49 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44fzWf6mq0z5BB; Thu, 11 Apr 2019 13:36:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1554982606; bh=FqSnqDC2jV5SJj2omfnc3y8MVG9E/46L5pk38RLV4Vw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jj2j96+KpHlAAU0cGy9mJw3BEyn+/BNVlqI7dW5HrNJbAm2l6BV7bG/UvjSUdmNb6 KHuIQtzkQqMdKtKATW2cWJHofGnNQJVH7iN4Ti0/Qf8lrRDVtCR3QFsyHu9+FOPhwm YkhrWjmSUbIeKBQGwPZMQuDs9orki0scVsY3mB98=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 9TEveuNgf7ki; Thu, 11 Apr 2019 13:36:45 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 11 Apr 2019 13:36:44 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id BD73879AFC; Thu, 11 Apr 2019 07:36:43 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BD73879AFC
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B11F740D358A; Thu, 11 Apr 2019 07:36:43 -0400 (EDT)
Date: Thu, 11 Apr 2019 07:36:43 -0400
From: Paul Wouters <paul@nohats.ca>
To: Martin Thomson <mt@lowentropy.net>
cc: add@ietf.org
In-Reply-To: <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com>
Message-ID: <alpine.LRH.2.21.1904110725320.21508@bofh.nohats.ca>
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>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/X9AFNk4UUtuqC9XNn1D_Gqez9Nk>
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: Thu, 11 Apr 2019 11:36:52 -0000

On Wed, 10 Apr 2019, Martin Thomson wrote:

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

But I assume it is also not your goal to reduce security for those who
chose mozilla products? You are offering your users a DNS system
override, yet you seem to find it acceptable if that results in a less
secure but more private DNS server being used. That is concerning.

> As a browser, we can't condition our behaviour on whether DNSSEC was present and valid for a variety of reasons (some of which we might discuss separately)

You can but you won't. But I agree there is no need to discuss that
here.

> but we do value resolvers that perform DNSSEC validation.

But you won't value it enough to make it a requirement, even though it
is a core part of the specification of DNS? Again, if you are
reconfiguring a system resource within the application, at the very
least do not reduce security. Requiring DNSSEC validation is a
no-brainer. Those who do not desire such security already can not use
DNSSEC by not sending the DO bit in the query, as you already not do
yourself in the mozilla products. But at this point, you would be
reducing my security and i will have to disable your privacy feature.

> Requiring query minimization is in keeping with the privacy goal,

Don't make this security versus privacy. Enhance privacy without paying
with security.

> whereas DNSSEC requirements would expand the scope more than we were comfortable with.

I understand your discomfort of still not supporting core fundamental
security technologies that prevent DNS spoofing. It should make you
even more uncomfortable that you are redirecting people to other DNS
servers that might actively support DNS spoofing. Having a policy where
you do not want servers to use RPZ DNS filtering, but not require them
to support the DNS protocol parts that can prove they are not
maliciously modifying DNS, is a policy mistake.

Paul