Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

Vittorio Bertola <> Sat, 25 August 2018 08:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13AAA129619 for <>; Sat, 25 Aug 2018 01:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3IL8HmYZXWki for <>; Sat, 25 Aug 2018 01:12:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F2041292AD for <>; Sat, 25 Aug 2018 01:12:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDE1C6A21C; Sat, 25 Aug 2018 10:12:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201705; t=1535184748; bh=NOtjEFiUpJ05ajz7RVz+gjZ7u7Wy6EnjWV86rQGqOb0=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=KUaTOgnHNGEJ0lFALzqrrvT9q1Tm8kKaLvkUZ4VVQZaUeKkLW2L4wytO5qqAqEfHT NlyJcUcGEyXrRL1c0fYYiZIb02QGvFH/2hfuMTzDAmFfyD6aoSpxYweVo7i7fc75nd 2PKdnzKYG0xVfZIWmknvNf2VkVlikb8EunatLPlr4S+hS+gUHIvnmCPCJZU3FzerII f6A7Boc5mxI89FQkWtLZMiw9gcDoRE3gr7XAGQch5ytv9JpDntEE9VPQpuvPtdI6Cp NT6s+YF8rwAy2ao7kEEqHcQ1pmAbAqLdBWCOcGVMaAacoOC2AoHTOzZB9G+E+LRVEp JX4vZGUlD8fTA==
Received: from null ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id BA65E3C0164; Sat, 25 Aug 2018 10:12:27 +0200 (CEST)
Date: Sat, 25 Aug 2018 10:12:27 +0200 (CEST)
From: Vittorio Bertola <>
To: =?UTF-8?Q?Vladim=C3=ADr_=C4=8Cun=C3=A1t?= <>, Paul Hoffman <>, Philip Homburg <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <>
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.0-Rev11
X-Originating-Client: open-xchange-appsuite
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Aug 2018 08:12:32 -0000

> Il 24 agosto 2018 alle 17.26 Vladimír Čunát <> ha scritto: 
> Still, personally I'd probably prefer to choose someone from a list of providers, as we might have quite a lot soon, and "I" might trust some of the names already, and the handshake will then verify that the name matches.

While having users in charge might in the end be the best thing to balance all the conflicting interests and threat mitigation needs, I am not sure that putting the user in front of a list of all the existing DoH resolution providers (thousands? hundreds of thousands?) is a great idea. 

In terms of user experience, to allow users to make an informed choice, the list would need to provide users with information on the policy of each server (see the current draft in DPRIVE) and it would end up being pretty hard to lay out and use in a meaningful way. Also, if you can't even find a way to transmit securely to the user device the information on the single DoH resolver that serves the local network, how can you maintain and transmit securely an updated list of all the existing DoH providers?
On the other hand, you could imagine that the application, or the OS, could create its own shortlist of "approved" DoH resolvers and transmit it securely from its own servers, or include it in the application's installation procedure. But this would open up significant policy/legal issues in terms of antitrust and fair competition among DoH providers.
I'm not saying that there's no way to do it properly, but it is not as simple as it looks. 

In the end, the policy of having your names resolved by default by a local server on your access network, while leaving you free to configure a different resolver that you find out-of-band if you want to, emerged over 30 years because it makes a lot of sense. I still have to hear a compelling technical or policy reason for the attempt to change this default and turn DNS resolution into yet another over-the-top service subject to global competition and market consolidation, other than "there are some big companies that would like to resolve the names for the whole world because they can gain from the data they would gather".

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
Office @ Via Treviso 12, 10144 Torino, Italy