Re: [Add] Mozilla's DoH resolver policy

Vittorio Bertola <vittorio.bertola@open-xchange.com> Thu, 11 April 2019 09:08 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
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 F01DF120287 for <add@ietfa.amsl.com>; Thu, 11 Apr 2019 02:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
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 RVsiZ5mnX6f1 for <add@ietfa.amsl.com>; Thu, 11 Apr 2019 02:08:38 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 A00D31200FC for <add@ietf.org>; Thu, 11 Apr 2019 02:08:38 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id F29E26A23C; Thu, 11 Apr 2019 11:08:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554973717; bh=x+lyP6NHnYh7FH0NdmWF8JN3KpFLaFEcQ5hS+IsJLvI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=X/3lPsg8XR88yPpjy6l3dvRyhz3m9QoD1qKluDjBM3HkIyZklVcZHQOlun4wEACK5 bWvyHXFvmrYbjVhrkaNjLAQaqIzyTGNp2A9BLAJLucB1pS2Dg6emMeMjmLACPketce LUssI22qAFQaVDfCS7KUqh0cW4wWk5D1o5PeovMyJbAsOxwpxybHxOcUg2debIRx0B EdGvKG5h7b3SVgFzNiRN65AomlKKFtaB4nAgLuXZCbOceV45EybGBp0DyMrabLhXRt x7ETP/GBD9ZEOBuqOoKDIkKoeWpkXBVkhe6Okf9PtBuk8eynOJLQPK/lWhKKn+JLze jBu/JEgQrQa/A==
Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id E4DFD3C0358; Thu, 11 Apr 2019 11:08:36 +0200 (CEST)
Date: Thu, 11 Apr 2019 11:08:36 +0200
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Ralf Weber <dns@fl1ger.de>, Martin Thomson <mt@lowentropy.net>
Cc: add@ietf.org
Message-ID: <994839978.18707.1554973716877@appsuite.open-xchange.com>
In-Reply-To: <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.1-Rev10
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/TlY0nhmHWJ6-FXW3iwVVUIlIsUE>
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 09:08:41 -0000

> Il 11 aprile 2019 alle 10.59 Ralf Weber <dns@fl1ger.de> ha scritto:
>
> So why not make DNSSEC validation in the resolver a requirement? It 
> doesn’t interfere with local policy and offers significant benefits 
> for the user. Validation in the client would be nicer, but requiring it 
> in the resolver is a good first step.

More generally, while I understand Mozilla's desire to ensure certain standards to their users, I think it would be better to have a broader definition of what a "good resolver" is, both in terms of scope (not just privacy, but DNSSEC etc), in terms of consensus (and the effort is already ongoing in DPRIVE) and in terms of compliance: I don't know Mozilla's plans for auditing their trusted resolvers (are there any?), but it would make more sense to have an independent industry effort that certifies resolvers, rather than having each of them go through multiple accreditation processes for multiple applications, which would raise entry barriers for public resolvers and, again, promote centralization. 

(Unless we imagine that the choice of resolvers and their accreditation criteria will be a competitive factor among applications, but that would IMHO pose a number of issues.)

Ciao,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy