Re: [Add] draft-arkko-abcd-distributed-resolver-selection
"Chris Box (BT)" <chris.box.ietf@gmail.com> Fri, 20 March 2020 18:22 UTC
Return-Path: <chris.box.ietf@gmail.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 C09C23A0DE2 for <add@ietfa.amsl.com>; Fri, 20 Mar 2020 11:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_IMAGE_RATIO_06=0.001, 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=gmail.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 XJgrWZY_rqTr for <add@ietfa.amsl.com>; Fri, 20 Mar 2020 11:22:21 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6E93A0DEA for <add@ietf.org>; Fri, 20 Mar 2020 11:22:19 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id z12so5770978qtq.5 for <add@ietf.org>; Fri, 20 Mar 2020 11:22:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A//7GUTeUWeLYUvJrdZjipT/H3nnucCBleatUVpArIw=; b=tR3Cnhz2BAfoULsg5ynfKGJQIMVUOKO3Jd3l+DazW7KfEyeYmcDHmKH7SQJStHN2UW Q9M/bVTELKGM9VSGYh+4va+6hQVHmMYMHhUepnEnKC4Hvx4T8X9jxUp0cUmC17+ShR0a yv7ziXGaXkUIVACXd3GydsaUiRFA0v7wa398TiUa473In6J9Nacb3M36KCyHN6CiYB4R VBvhTV3sgJLifSnvLtxsiWKSccPgCLWNRkIJ1LCDuJT//PkCbBQVDfpScRvufyoMU+d2 8/uTh4Fh79z4wkjMvA1yUfaKTgKWosoo2I6+Bsz+un7Mp7utG0eqexIyOYxFD0OLmAqw uOdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A//7GUTeUWeLYUvJrdZjipT/H3nnucCBleatUVpArIw=; b=qj5xswZzTVouOtc+T3yACGAPm6/+OVeXWvDWYVTGG2YUKbODDRsuarJWVsjXV5ElyR qpB8N6H26YmuoagnH1Cwq3txHKDto/qoeYDbfPGJG9xSoaFI76tJZIZ/Eee2U3uWQr/+ /ep1A/uVwc2xqGuKo59pxx8dRX427S48n/6zrKLxGIn2ag1lAOWIvPssnhNIEnFmS07O 6Y76DGKUwsJ/FHud1CGufiG0O5KOIEBPwaNkPRGlmJA2bVhIAAXAAXmK1uU6tvor9e+O Xk/CQlsGtnoU+QdzuRZYdHUMP/aQx182xIeLYzuYngBQjp4ZfFUFhjGVNPUcEorWxwY7 c7yg==
X-Gm-Message-State: ANhLgQ11T33qTJoPVoUGgT3UhUX0ahlWzAOscLvXN77LIL/rMSHLlb/8 hbaSPDng2viuOcoKnD5RxWHGAHROnhsLIbgdpWk=
X-Google-Smtp-Source: ADFU+vuCpMOJAj5OxgCunmY9KdliCTFOqIHfzsP41fxPj6zhBq2SpaSZ6hz/Y6JfNFsavwmftX5PtntJxP5fa8Xlq5s=
X-Received: by 2002:ac8:4a08:: with SMTP id x8mr9241242qtq.32.1584728538246; Fri, 20 Mar 2020 11:22:18 -0700 (PDT)
MIME-Version: 1.0
References: <CA+9kkMDvX7e0WkRMmJtf33GwMQQ1rAGny87UwneA6znCom_85Q@mail.gmail.com>
In-Reply-To: <CA+9kkMDvX7e0WkRMmJtf33GwMQQ1rAGny87UwneA6znCom_85Q@mail.gmail.com>
From: "Chris Box (BT)" <chris.box.ietf@gmail.com>
Date: Fri, 20 Mar 2020 18:22:06 +0000
Message-ID: <CACJ6M17rjhta9rqFHAJ_JaugRiCR7xvAChww0uO912-NayQwEQ@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: ADD Mailing list <add@ietf.org>, Jari Arkko <jari.arkko@piuha.net>, Martin Thomson <mt@lowentropy.net>
Content-Type: multipart/related; boundary="00000000000096fa1a05a14d5dec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/38bJcQA_RZwRtTNI3Q4jNpFfvUg>
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: Fri, 20 Mar 2020 18:22:37 -0000
Ted, Jari, Martin, In preparation for the first presentation on Tuesday, I've had another look through your draft and it's raised some questions in my mind. Section 3 introduces the premise that the client selects a set of trusted resolvers, excluding all less trusted ones. It doesn’t really say this, but I think each resolver in the set needs to be operated by a different party, otherwise the activity seems to be pointless. Do you agree? If you do, the premise implies the set must include at least one resolver NOT operated by the provider of the local network. We then get onto the problem briefly mentioned in section 6.2, namely different resolvers might have different policies with respect to blocking or filtering of queries that lead to clients receiving inconsistent answers If I compare the above to the set of perspectives outlined in ICANN SAC109, my expectation is that the resulting net change in the ability to meet their needs is as follows: 4.1 (Parents): Negative 4.2 (Enterprise Network Managers): Negative 4.3 (Dissidents, Protesters and Others): Positive 4.4 (Internet Service Providers): Negative Would you agree with this assessment? Or have I missed something crucial? I'm normally optimistic so let's assume there is a way to mitigate the negatives. Let’s now focus on whether the impact to privacy is always positive. I think there is a case where it may be weaker than the status quo. Imagine a normal residential home. This one has five different wifi clients, with a single recursive resolver (A) outside the home, on the internet. This is shown below (apologies to anyone reading the plain text version). [image: Normal.png] Resolver A sees the merged traffic of all 5 clients, coming from a single IP address. With the client-based selection mode (section 4.1), and two resolvers chosen (A and B), those resolvers can learn more data about the specific clients: [image: With two resolvers.png] Of course A can individually separate clients 1, 3 and 5, because even though they share an IP address, they've all set up separate TLS sessions. Is this is a legitimate privacy issue? I would be grateful for your thoughts, either on the list or during the presentation on Tuesday. And if anyone on the list has a view, particularly if there is a way to modify the text such that negative impacts can be reduced, that would be most valuable. Thanks, Chris On Tue, 25 Feb 2020 at 18:01, Ted Hardie <ted.ietf@gmail.com> wrote: > 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. > > Do the chairs and the working group agree? If so, can we ask for agenda > time at IETF 107 to present? > > thanks, > > Ted > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add >
- [Add] draft-arkko-abcd-distributed-resolver-selec… Ted Hardie
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Eric Rescorla
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Adam Roach
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Erik Kline
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Stephen Farrell
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Vittorio Bertola
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Chris Box (BT)
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Ted Hardie
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Rob Sayre
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Chris Box (BT)
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Rob Sayre
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Vittorio Bertola
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Andrew Campling
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Rob Sayre
- Re: [Add] draft-arkko-abcd-distributed-resolver-s… Jari Arkko