Re: [dns-privacy] [Add] Draft on the use of multiple recursive resolvers

Vittorio Bertola <vittorio.bertola@open-xchange.com> Sun, 17 November 2019 06:30 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 95BD312009C; Sat, 16 Nov 2019 22:30:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, 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 QYFqe_7JPdyF; Sat, 16 Nov 2019 22:30:49 -0800 (PST)
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 4F9C812007C; Sat, 16 Nov 2019 22:30:49 -0800 (PST)
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 621666A279; Sun, 17 Nov 2019 07:30:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1573972247; bh=yODm/5H8700lnLmtLdXRefNnKgWJud8gLrBX2DV5/Qw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=ZAX5y/en8t1XOTbbDgNjW9z+guEdMTkPIe0NdmHJMvM0eHmoIpLU0ARG3pf6M5dGp /sSDFHslMrdyD3RWPAglKyQBcg8lMUohv+0QukJh4jqi41QOu9cBCF0wCfxXjvGpKG as0dxBY8mnzbNp9g/Xf0iCh78sMLl61/xc+6FlhSrmV8ZMHFrGYILva5rMTZQUsxtx AgWdFEeg6k9nYnN9f6qwbJhNgntQV9klqVnXjD3LJuq9/pDqujzdN5SYjZJOj+RprF gBE7To5VKu2Vmz7TCGyXx+SlDk/lSObtFI6eNP9b5lGQ7TTOsUu1PYbS1tRnntg0uv G5jw2+dTgmsXA==
Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (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 515AE3C02DA; Sun, 17 Nov 2019 07:30:47 +0100 (CET)
Date: Sun, 17 Nov 2019 07:30:47 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Reply-To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Jari Arkko <jari.arkko@piuha.net>, ADD Mailing list <add@ietf.org>, dns-privacy@ietf.org
Message-ID: <1017702565.6223.1573972247221@appsuite-gw1.open-xchange.com>
In-Reply-To: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net>
References: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.2-Rev17
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/nIA_cFguPgLIx6W2JTPabRZS0P8>
Subject: Re: [dns-privacy] [Add] Draft on the use of multiple recursive resolvers
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: Sun, 17 Nov 2019 06:30:52 -0000


> Il 16 novembre 2019 08:38 Jari Arkko <jari.arkko@piuha.net> ha scritto:
> 
>  
> I wanted to point people to a draft that Martin, Ted, and me recently submitted
> on the use of multiple resolvers. This is early work; comments and additional
> analysis appreciated.
> 
> https://tools.ietf.org/html/draft-arkko-abcd-distributed-resolver-selection-00
> 
>    This memo discusses the use of a set of different DNS resolvers to
>    reduce privacy problems related to resolvers learning the Internet
>    usage patterns of their clients.

Well, as you recognize in the draft itself, this is just "a narrow aspect within a bigger set of topics", so I would find it more useful to start from the broader discussion, the one you hint at in the final part of the draft: is there a reason to change the current model that has been generally adopted until now, i.e. the user picks (or is supplied) a resolver and all the queries go through it? What are the advantages and disadvantages of spreading the queries instead of using a single resolver?

Even in terms of privacy, I would not be so sure that spreading the queries to multiple parties could ever provide more privacy than sending them only to a single trusted party, even if we could actually come up with a distribution strategy that solved the problem of letting all resolvers see most of your traffic over time. The original point of contention in this discussion was the browser sending the queries to a different resolver than the one they were meant for - not the fact that a single resolver was being used. Also, the entire legal data protection architecture in Europe relies on the fact that the user knows and authorizes each single party that gets a share of their data, which is philosophically the exact opposite of a model in which data start to be sent here and there in ways that the user is unable to control.

Moreover, you cannot discuss these alternatives only in regard to privacy, as the choice will affect many other dimensions. By choosing a specific resolver, users can get better performance or additional services - how could this work if their queries started to be distributed? ISPs use their resolvers as a network security platform and as a way to make their Internet access service faster than competitors; it is unclear why they should spend considerable money to provide big scale resolvers if these resolvers will not be part of their service any more, and will rather be used at random by random users every now and then (so you would, again, reduce the number of mainstream resolver providers to the few usual suspects that can afford the cost no matter what). Then there's all the lawful interception and content blocking part, which people here tend to dismiss, but governments won't. So I am afraid that if you only discuss a single part of the problem, you will end up worsening the ot
 hers and not solving much.

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