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
>