Re: [DNSOP] EDNS0 clientID is a wider-internet question

Christopher Morrow <> Tue, 25 July 2017 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2906131771 for <>; Tue, 25 Jul 2017 07:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g_1TGM9vm86M for <>; Tue, 25 Jul 2017 07:38:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 441C61270B4 for <>; Tue, 25 Jul 2017 07:38:33 -0700 (PDT)
Received: by with SMTP id d145so63303565qkc.2 for <>; Tue, 25 Jul 2017 07:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=emeK4f/4DUS30gKyk4ayeiOvAmk1rZ/hjiJwKfHgQYk=; b=b32bowKRgA5EwaYSzDrKJ4tUMgGUM7lW7z9PHlVP+PDsMRR/3N0VBdNOIStAKfrl2l 9mEmOdXe3sZvJ72dB/Fn2h494zKdzxKvFR1xn+MJovsJVmQjYHvoyyNIZ5C2TKlKbGVz xpy/0me45ZgsHNzql7iuCbqfCZpKKDghq8Bj+VqO6KZ3BQ/5z8xt5A2aE5e3ntSC92/n tH3GTCU+zrppHftKusm3ydJf4pl51Dmio/7GwUoAfqtTl6Yw5tbnD6BgUgEQ4Wdv1aNc SRKyxXsqZXXgYzAEZ95ocGfKh9qFN35ta6FLHDKiGJ0b/eb0nTbMtfQV50pbX+caJjID ZDxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=emeK4f/4DUS30gKyk4ayeiOvAmk1rZ/hjiJwKfHgQYk=; b=AP3ptVi8xLR9nsCC6QpTUdFd6NG2bwQ/auUCdl7jdzzefcFOh/TsFDPMC/meBk5r9l pYVkm4vpqRBChpTwi0XDOVN9Q6egHI+IfDHNipCGx3fMd28ZNP/Tj5GFAjtaHcvJBT5p pA4Btu8Hsp++0VBlYRMVZQItKm2ADQoGBAw+N2wLeIeB0T+a1omquvMU2X9P4Hj/t18q iIQCRikGpwmF1hHhzj2h9J9SbD4L7S0RmIE+3Jkuv2HJ3W2dUm1ivLuz968SIpIgPstq 3GWYMXLoZB2iifNHGlidYxfmyvx9s+nxwY8+FoU1xqDzCIfTLttwdplhZKsuCpYdxngw w/oA==
X-Gm-Message-State: AIVw1133c9qt/jPqrMwRodVNcpix8kSIVilzwqtpgbohTsx26V2+efRC hZu64SYDJa6irOl2rllHEPsewQU4jY65
X-Received: by with SMTP id x136mr8954940qka.254.1500993512366; Tue, 25 Jul 2017 07:38:32 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 25 Jul 2017 07:38:31 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Christopher Morrow <>
Date: Tue, 25 Jul 2017 10:38:31 -0400
X-Google-Sender-Auth: HdB_LFt2rzD8RfGcLS_gIHwT2ao
Message-ID: <>
To: Ted Lemon <>
Cc: George Michaelson <>, dnsop WG <>
Content-Type: multipart/alternative; boundary="001a114a826c1d693b05552549e2"
Archived-At: <>
Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jul 2017 14:38:36 -0000

darn, I keep reading 'client-id' as 'client subnet' :( back in my hole I go.

On Tue, Jul 25, 2017 at 9:53 AM, Christopher Morrow <
> wrote:

> On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon <> wrote:
>> On Jul 24, 2017, at 8:59 PM, Christopher Morrow <>
>> wrote:
>> and at the cache->auth layer it's potentially the case that the provider
>> can say: "use precision of /24" or "use precision of /17" ? So, there's
>> really not much "pii" that can be worried over at the
>> provider-cache-resolver (they already know who you are...) and they
>> (provider) can decide how much granularity is "important" to release to the
>> upstream authoritative cache.
>> There is no such thing as an upstream authoritative cache.   The
>> filtering is being
> apologies, 'upstream (from the cache resolver's perspective) authoritative
>> done at the cache.   This is not client subnet: this is client ID.   So
>> the cache, which is not authoritative, is receiving PII about a specific
>> client machine.   Being able to
> I agree with this, the cache resolver sees the client's IP address.
>> filter the PII at the CPE would indeed improve privacy in this case; the
>> problem is that the CPE has to have a UI or API that allows that to happen,
>> and they don't.
> I don't think the CPE is the answer, the cache-resolver CAN decide to send
> along in it's edns0 option: "" instead of "". Or it
> seems to me that this is a fine knob to add to resolver software... granted
> you'd need some extra config about your client subnets in use.
>> The reason DNS filtering is useful is not that it is forced upon the end
>> user, but that it allows devices that use the default cache to get
>> filtering in a way that does not
> I don't believe the goal of the draft is to enable filtering.
> Certainly for a nation-state actor you could see: "Oh, now I know what
> subnets use the resolver over there, so I can limit useful replies, or
> steer requestors toward 'better/approved' content'
>> depend on the software installed on them.   So e.g. your IoT device can
>> be infected by a worm but not actually exfiltrate any private information
>> to the attacker, because the attacker's DNS is blocked.
> you seem to be conflating a few things here... or using 'content
> filtering' in a different way here than before in this response.
>> Being able to know that a particular device is a particular device is
>> actually quite useful in this context; unfortunately, there is no way to
>> distinguish "useful" and "personally-identifying".   Even if you only
>> identify the IoT devices in your home, by doing so you reduce the search
>> space for identifying the other devices.
> I don't think the draft is aiming at 'device' as much as 'region of the
> network'. The cache resovler COULD choose to send /32 (or /128) level data
> in the edns0 option, but that seems counterproductive, and a bit invasive.
> -chris