[Driu] DoH Digests and privacy risks

Vittorio Bertola <vittorio.bertola@open-xchange.com> Thu, 19 July 2018 22:55 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: driu@ietfa.amsl.com
Delivered-To: driu@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DFBAE130EA7 for <driu@ietfa.amsl.com>; Thu, 19 Jul 2018 15:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 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] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id myIwX13cSJQ5 for <driu@ietfa.amsl.com>; Thu, 19 Jul 2018 15:55:18 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE61F130DD2 for <driu@ietf.org>; Thu, 19 Jul 2018 15:55:17 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 91F066A27C for <driu@ietf.org>; Fri, 20 Jul 2018 00:55:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1532040915; bh=xRHezSnMZ0znuE414QWyX2f7oATrCLQSWtrncad7Kjs=; h=Date:From:To:Subject:From; b=uJy6tqM+dnD10IsI3qP5EXG6Nf3PuDhtljwd85sVy+ZYG2lYMP2x7JciIlXFXVkEm HA0GZT9rWIwy0q4cvk5qBoZfjDi2xvuV0f/v8EAGfohWqJxQR4RySlJDsXvgTocXX5 NJodgOHOMo0iIJCStwzAJa+LkMkh781HAtQcPTFMHTLA6SGN9PKlHoskz3Pltu+Wf0 OTTDsjAj3O4sovgQJPOGvPWE/nWzZa6D7Lh9VpFw3AZsaf+Gh63Fol7e+1wvE1w4P2 mO74U4XyqbMSDum4YYl4NJt+TRw7suVmoZTYeqiwxWVT4fOLPm8K1mDUpfM65jciO4 nal6pHVZRMciA==
Received: from null (appsuite-gw2.open-xchange.com []) (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 8432F3C102F for <driu@ietf.org>; Fri, 20 Jul 2018 00:55:15 +0200 (CEST)
Date: Fri, 20 Jul 2018 00:55:15 +0200
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: driu@ietf.org
Message-ID: <2065665402.3.1532040915491@appsuite.open-xchange.com>
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-Rev10
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/jJo9wy0kLXg9ZyOWFbU93w7n5jk>
Subject: [Driu] DoH Digests and privacy risks
X-BeenThere: driu@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <driu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/driu>, <mailto:driu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/driu/>
List-Post: <mailto:driu@ietf.org>
List-Help: <mailto:driu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/driu>, <mailto:driu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2018 22:55:20 -0000

this started as a comment on Mark Nottingham's DoH Digests draft as presented today in the BoF, but in the end it deals with more fundamental issues with DoH, so I'm sharing it with the list.

I am a DNS policy guy, not an HTTP guy, and have not been involved in DoH until now. So I was struck by some statements:

1) While encrypted DNS transport removes the potential for MITM eavesdropping, it cannot do anything against privacy breaches by the entity running the resolver. The presentation mentioned, as the intended consequence of DoH, that possibly we will get our name resolution from "big websites". Unfortunately, the business model of most big websites today relies on user data monetization, targeted advertising and so on; so these people would actually have an economic incentive to log and correlate the user's DNS query history with other information that they gather elsewhere, much more than the network access providers. So IMHO in this regard DoH is threatening the user's privacy, rather than increasing it.

2) The draft, right in section 1, assumes that it's the "application's vendor" that gets to vet which DoH servers are good for the user. One would expect that it's rather the user that has the right decide who to trust with their data - this is also the principle underlying most privacy laws around the globe. The user is of course free to delegate that decision to a trusted application vendor or to anyone else, but in the end, the architecture should be conceptually designed to empower the users, not application vendors. Also, if one thinks at how many applications are responsible for user data mistreatment and abuse, this looks like another dangerous policy decision.

So, either I do not understand the privacy threat model that is meant to be addressed by DoH, or such model is perhaps incomplete; yes it's great to encrypt DNS traffic so that no one can sniff or alter it, but that's not the main source of privacy abuses today on the Internet; tracking, centralization and correlation of user activities across multiple services are.

I looked into the main DoH draft as well, but at first sight, notwithstanding the final sections, I could not find any analysis of these security and privacy issues. So while in the end I really like the idea of spreading DoH traffic across multiple services to make tracking and correlation harder, I would first make sure that we have a shared understanding of all the privacy risks that have to be mitigated in this "new DNS ecosystem", and we work on an architecture that addresses them all.


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