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
- [Add] Mozilla's DoH resolver policy Paul Hoffman
- Re: [Add] Mozilla's DoH resolver policy nusenu
- Re: [Add] Mozilla's DoH resolver policy Paul Wouters
- Re: [Add] Mozilla's DoH resolver policy Martin Thomson
- Re: [Add] Mozilla's DoH resolver policy Ralf Weber
- Re: [Add] Mozilla's DoH resolver policy Valentin Gosu
- Re: [Add] Mozilla's DoH resolver policy Vittorio Bertola
- Re: [Add] Mozilla's DoH resolver policy Jim Reid
- Re: [Add] Mozilla's DoH resolver policy Ralf Weber
- Re: [Add] Mozilla's DoH resolver policy Manabu Sonoda
- Re: [Add] Mozilla's DoH resolver policy Valentin Gosu
- Re: [Add] Mozilla's DoH resolver policy Ray Bellis
- Re: [Add] Mozilla's DoH resolver policy Ralf Weber
- Re: [Add] Mozilla's DoH resolver policy Daniel Stenberg
- Re: [Add] Mozilla's DoH resolver policy Paul Wouters
- Re: [Add] Mozilla's DoH resolver policy Vladimír Čunát
- Re: [Add] Mozilla's DoH resolver policy Ralf Weber
- Re: [Add] Mozilla's DoH resolver policy Vladimír Čunát
- Re: [Add] Mozilla's DoH resolver policy Adam Roach
- Re: [Add] Mozilla's DoH resolver policy Peter Saint-Andre
- Re: [Add] Mozilla's DoH resolver policy Peter Saint-Andre
- Re: [Add] Mozilla's DoH resolver policy nusenu
- Re: [Add] [Ext] Mozilla's DoH resolver policy Paul Hoffman
- Re: [Add] [Ext] Mozilla's DoH resolver policy Peter Saint-Andre
- Re: [Add] [Ext] Mozilla's DoH resolver policy Adam Roach
- Re: [Add] [Ext] Mozilla's DoH resolver policy Brian Dickson
- Re: [Add] [Ext] Mozilla's DoH resolver policy Adam Roach
- Re: [Add] Mozilla's DoH resolver policy Vittorio Bertola
- Re: [Add] Mozilla's DoH resolver policy Wes Hardaker
- Re: [Add] Mozilla's DoH resolver policy Peter Saint-Andre
- Re: [Add] Mozilla's DoH resolver policy Ted Hardie
- Re: [Add] Mozilla's DoH resolver policy Wes Hardaker
- Re: [Add] Mozilla's DoH resolver policy Ted Hardie
- Re: [Add] Mozilla's DoH resolver policy Wes Hardaker
- Re: [Add] Mozilla's DoH resolver policy Christian Huitema
- Re: [Add] Mozilla's DoH resolver policy Mark Andrews
- Re: [Add] Mozilla's DoH resolver policy Wes Hardaker
- Re: [Add] Mozilla's DoH resolver policy Vittorio Bertola
- Re: [Add] Mozilla's DoH resolver policy Vittorio Bertola
- Re: [Add] Mozilla's DoH resolver policy Livingood, Jason
- Re: [Add] Mozilla's DoH resolver policy Livingood, Jason
- Re: [Add] Mozilla's DoH resolver policy Salz, Rich
- Re: [Add] Mozilla's DoH resolver policy Ben Schwartz
- Re: [Add] Mozilla's DoH resolver policy Adam Roach
- [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] ECS privacy concerns, alternatives? Mark Delany
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] ECS privacy concerns, alternatives? Mark Delany
- Re: [Add] Mozilla's DoH resolver policy Christian Huitema
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] Mozilla's DoH resolver policy Geoff Huston
- Re: [Add] Mozilla's DoH resolver policy Ralf Weber
- Re: [Add] Mozilla's DoH resolver policy Paul Wouters
- Re: [Add] ECS privacy concerns, alternatives? Erik Nygren
- Re: [Add] ECS privacy concerns, alternatives? Joe Abley
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] ECS privacy concerns, alternatives? Joe Abley
- Re: [Add] ECS privacy concerns, alternatives? Paul Hoffman
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] Mozilla's DoH resolver policy Hollenbeck, Scott
- Re: [Add] Mozilla's DoH resolver policy Adam Roach
- Re: [Add] ECS privacy concerns, alternatives? Puneet Sood
- Re: [Add] ECS privacy concerns, alternatives? Erik Kline
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson