Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis

Vittorio Bertola <vittorio.bertola@open-xchange.com> Mon, 26 August 2019 13:38 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F2612004C; Mon, 26 Aug 2019 06:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8oVfVXmfdbj; Mon, 26 Aug 2019 06:38:49 -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 EDE46120047; Mon, 26 Aug 2019 06:38:48 -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 B7E756A284; Mon, 26 Aug 2019 15:38:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1566826724; bh=gG9691e1B/KrWlXXn+iIdQgAD3Kn/4xsIFDFGPlYrP0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=Whe2cm/xJGwP6f/pfE4ddb7zRQaPXN6vQxizBqLv609O9rvCYmSynDF0uZsyBl3lz Nx7HTLbpL9Q8nZ0G5jP+N/9oH45bDkpfrmNzB6X4zUjBXSn66aczGR++W7VND46O+8 n11sNq8KLZ8Zo02Z/wdMbrYwecjDPULUB9GiG5/41FnWW7jyFgYnnJU9wYT2qgTnmQ 66RimXsFX/LGTa3IIuFFd61gpB/nwGLcRDDT99XXR5YRKGydzsh+hX6HnUB1QrdPP5 T4tFu+o+vPcgSvOBMrrFcQEjkIB6VIswORNvJTu1i/AJeUy7Zvm6jtCE1Y/LkqUjwk 0g2c+kDuuW2Cw==
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 AAE1B3C0911; Mon, 26 Aug 2019 15:38:44 +0200 (CEST)
Date: Mon, 26 Aug 2019 15:38:44 +0200 (CEST)
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Reply-To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Tim Wicinski <tjw.ietf@gmail.com>, dns-privacy@ietf.org
Cc: dprive-chairs@ietf.org
Message-ID: <1878309801.4612.1566826724648@appsuite-gw2.open-xchange.com>
In-Reply-To: <CADyWQ+EY14GdvEv7f0X6d=GNp6Kbdrkr6rNchszOgs_mf0zUXA@mail.gmail.com>
References: <CADyWQ+EY14GdvEv7f0X6d=GNp6Kbdrkr6rNchszOgs_mf0zUXA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.2-Rev11
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/lkDk9ywN0vE9nQsijfV4-kA_wAs>
Subject: Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2019 13:38:51 -0000


Il 16 agosto 2019 13:49 Tim Wicinski <tjw.ietf@gmail.com>; ha scritto:



This starts a Working Group Last Call for draft-ietf-dprive-rfc7626-bis


Current versions of the draft is available here:

The Current Intended Status of this document is: Informational

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out. 
If someone feels the document is *not* ready for publication, please speak out with your reasons.
Here are my comments after going through the document. I think it still needs further work, reflecting how the discussion on DNS privacy has advanced since the original draft was written. I am not providing text yet but I am happy to work on it if useful.

- On section 2.1: I think the DNS today holds a considerable amount of "data" (not necessarily personal information, but the section seems to deal with data in general) that are not meant to be "public"; this is only hinted at with a short, non-exhaustive incidental ("access control lists and private namespaces notwithstanding"), and only for authoritatives.

The reality is that recursors also have "DNS data" which is not meant to be known to the public and goes beyond private namespaces; for example, different replies for public names, to be given to specific clients (e.g. identified by network of origin or by some kind of client detection mechanism). This data might be sensitive, both in terms of security (it might help attackers from the outside if disclosed) and in terms of privacy (e.g. if I configured my resolver to block certain categories of websites, both the list of blocked websites and the fact that I block them can be confidential).

I am not completely sure of the intended meaning of this section and why it fits here, given that all the other 2.x sections are a catalogue of risks, but an expanded mention of the fact above would make sense.

- On section 2.4.2: this is an abstract discussion of privacy risks in encrypted transports, but then I would have expected to find here all the well known considerations on the additional privacy risks that are created by the use of specific transports and especially HTTPS: the potential (although denied in the standard) use of HTTP cookies, the fact that even without cookies well known and readily available techniques for fingerprinting and tracking exist, the risk of easy correlation between HTTPS requests that bear DNS payload and other HTTPS requests, etc.

I did not find anything, but then I found 2.5.1.2, so I thought that perhaps the intention was to use 2.4 to deal only with cases in which third parties break the encrypted protocol, and defer the rest to 2.5.1; still, 2.5.1 is about the risks deriving by resolver behaviour, but some of the issues are tied to potential cooperation between the client and the resolver to track the user, or attack opportunities that are facilitated by inappropriate client implementations (e.g. a DoH client that added too many headers and made fingerprinting very easy), so these look to me more like issues connected to the protocol, than to the resolver side only.

Also I don't particularly like framing this as "DoT vs DoH" - it would make more sense to me to have (in 2.4.2?) two separate sub-sections, one per each encrypted protocol, describing the risks of each of the two. I would rather leave 2.5.1 for a discussion of risks specific to the choice of recursive resolver and to its behaviour - this leads me into the next point.

- On section 2.5.1 but also in general: I think the discussion in the few last months has identified the centralization of DNS queries onto a few resolvers as a big risk for DNS privacy, perhaps the biggest one in the near future - yet I cannot find this discussion anywhere in the document. This risk should be mentioned in the introductory parts already, and then it should be discussed in detail, possibly here, examining the potential for centralization that each protocol has, and the privacy risks of the various deployment models.

- On section 2.5.3: I find the section as currently written quite problematic. In practice, it seems mostly focused on bashing DHCP as a way of configuring networks, but it also seems to suggest that the various techniques mentioned in the paragraph ("divert traffic by providing lies for some domain names", "transparent DNS proxies in the network that will divert the traffic intended for a legitimate DNS server"), which are common network administration and service provision techniques for entirely legitimate reasons, are necessarily associated with "rogue servers". On the other hand, there is only a small hint at the end (and only associated with "malware") that not just the network, but applications on your device might monitor or redirect your DNS traffic.

So I would rewrite the section completely, and I would make it about the basic privacy risk, which is having the user's DNS data go (or be copied) to a server that is not the one that the user has entrusted with their personal information. This server is "rogue" from the user's viewpoint, but it could be a perfectly reputable and legitimate resolver, just not the one the user wanted; this is why I also do not like the term "rogue", which seems to suggest a hidden server run by black hats.

Any way of changing the user's resolver preference - be it done by the network or by applications - creates a privacy breach, unless it has been authorized by the user or is allowed by applicable legislation (e.g. for network security reasons). This should be the main point of the section.

- On section 2.5.5: this is also problematic. First of all, it's not an attack on servers but on the transport, and it applies potentially to any transport and not just encrypted ones, so it should go in 2.4, unless you want to treat it like a particular case of 2.5.3 which leads you to adopt a different resolver not by intercepting packets but by depriving you of alternatives.

Then, there should be a recognition that there might be plenty of valid reasons for blocking access to remote resolvers (e.g. network security needs) that could outweigh the risk to privacy, which is anyway optional (it only exists if the user actually does not trust any of the "allowed" resolvers and specifically wants one of the blocked ones).

Moreover, there should also be a discussion of the symmetric risk, i.e. your device, application or operating system blocking access to resolvers you might want to use, for example by disallowing you from choosing them in their configuration, leading you to adopt other resolvers which you do not trust in terms of privacy.

- On section 2.6: it is interesting and useful but feels a bit out of context. As it is connected to the risk of correlating DNS queries with data from other sources, could it perhaps fit in the discussion on DNS centralization?

Apologies for the long message, and I'm happy to work with the authors to address my comments.

--

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