Re: [Add] draft-arkko-abcd-distributed-resolver-selection

Vittorio Bertola <vittorio.bertola@open-xchange.com> Wed, 26 February 2020 10:20 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 370893A124E for <add@ietfa.amsl.com>; Wed, 26 Feb 2020 02:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 vzDSb2wqzX2k for <add@ietfa.amsl.com>; Wed, 26 Feb 2020 02:20:38 -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 47EAD3A124C for <add@ietf.org>; Wed, 26 Feb 2020 02:20:37 -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 8AEA56A275 for <add@ietf.org>; Wed, 26 Feb 2020 11:20:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1582712435; bh=yw9AzWKnWabuJas9V2doNJENWf2b4hpMwhqf+GymvHI=; h=Date:From:To:In-Reply-To:References:Subject:From; b=bidPQ8UkcsRma92oIBguc0lv/f7qfp2g4tMgF13YKF29uE080tfRKp3lVWZLVb+D4 GkASBNSGAPr3KsyECZ1H9a4BoSTPHg/A0ZAGO6iQeXY2uvM5rRrCBQ9TL/Q3FDi1AZ 3l3C7zqJlCH+mJ1fiuQpU2mNG3DKbnY3FrPGwj2gN3xZz192o31rPT7CsLfDTVltPw v0zvXKAWEIH+pFDOOdw6layA8IAeWKVx/ErPJ9OxhxJOQJPW4RWz8bd5y7/Afw6pJX Qs9bihkPjCLiZeMJoHuuSVlJ/QGrBtHkqw8TrMEBqOTl5DDls5+OS1WL4Dr6Bk9vrq EWKfRrvwKegnQ==
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 7E17A3C0331 for <add@ietf.org>; Wed, 26 Feb 2020 11:20:35 +0100 (CET)
Date: Wed, 26 Feb 2020 11:20:35 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: ADD Mailing list <add@ietf.org>
Message-ID: <1280546249.15154.1582712435424@appsuite-gw1.open-xchange.com>
In-Reply-To: <CA+9kkMDvX7e0WkRMmJtf33GwMQQ1rAGny87UwneA6znCom_85Q@mail.gmail.com>
References: <CA+9kkMDvX7e0WkRMmJtf33GwMQQ1rAGny87UwneA6znCom_85Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_15152_651447221.1582712435410"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.3-Rev5
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/add/6Qs5TufjO5faYoUJxtdEv6MhDY0>
Subject: Re: [Add] draft-arkko-abcd-distributed-resolver-selection
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: Wed, 26 Feb 2020 10:20:42 -0000

>     Il 25/02/2020 19:00 Ted Hardie <ted.ietf@gmail.com> ha scritto:
> 
> 
>     Howdy,
> 
>     Jari, Martin, and I put together draft-arkko-abcd-distributed-resolver-selection https://datatracker.ietf.org/doc/draft-arkko-abcd-distributed-resolver-selection/?include_text=1 to start a discussion on whether DNS clients can improve their privacy through the use of a set of multiple recursive resolver services.  We think it might be in scope for ADD, since the charter says the group "will focus on discovery and selection of DNS resolvers" and this discusses the impact of selecting more than one. 
> 
This is another idea that looks great from a purely technical standpoint but a total nightmare in terms of policy, both public and local, both legal and technical (e.g. network security). Also, it only increases privacy if by privacy you mean spreading your data as much as possible among many parties, but not if (as per the GDPR's data minimization principle) by privacy you mean minimizing the amount of data you give away and the number of parties who know something about you - let alone the discussion on whether this model in the end would lead to more or less centralization in terms of DNS providers.

For example, if the client, rather than using a single resolver in its own country that offers reasonable privacy guarantees, spreads its queries among N resolvers that are all or almost all run under a single foreign jurisdiction, this creates an additional risk for surveillance by that country's national security agencies that did not exist before, and that might outweigh any advantage gained by spreading the queries across multiple resolvers.

This said, of course I'm fine with a presentation, but I challenge the draft's conclusion that these strategies are "generally beneficial in the common cases". If this ever becomes a working item, the analysis should cover all the pros and cons and the discussion should go well beyond the IETF to understand the conditions for doing this that would make all stakeholders happy (like it should have been done with DoH).

--

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