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

Ted Lemon <mellon@fugue.com> Tue, 25 July 2017 09:55 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C8A127010 for <dnsop@ietfa.amsl.com>; Tue, 25 Jul 2017 02:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 f7FUvKg2nrSe for <dnsop@ietfa.amsl.com>; Tue, 25 Jul 2017 02:55:16 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 96655131C35 for <dnsop@ietf.org>; Tue, 25 Jul 2017 02:55:13 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id r14so50699545qte.4 for <dnsop@ietf.org>; Tue, 25 Jul 2017 02:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0OgKzhEXkJ2Pit3wzKkBvvA9m07I3bJ78N0zrnshwLM=; b=atfGd2+YjbM7Oxa/dxu8WB59gAunoVMWPwdJonmGrvri9cIVctnklDZQSBHeIGgTLq frGxyceHo6gZUSlExTzn01/6KSTw5Zu9ZefdS2Cep5E9MG/RWnNzqJkfSHpGM7Sxwo0y BhhuCYOTiKr7T/5/T1S2jByDrzhSpLN9l7SW7OHT9nBT8GyGR81rI2VYnemKDLaTqZGn I370DG7x3PxMaMTkOyECYabiuIwHL9obDvR2XVK5kFaB0hWz2Tu5Z1+xdLQVpZb7Sb2e aqD7Oibj+DqRD5lHUNxoaMzul00fAWbtRIDSaKwnzil5Dk4GDgCDc1mH3Ji9ZN/OLBA2 K/sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0OgKzhEXkJ2Pit3wzKkBvvA9m07I3bJ78N0zrnshwLM=; b=T3K+SlwrCM0TojwKhLntF7ZR6D95dxJX7wMGnus88YEgd2UBtejTPVdzODCDXe3/1G QU9F7Qi11auhtKlI/hha8Z7weuu/8Fy9jtkPES1Mvt3c/ZOITy1dZsIHN4eJj+anYUxh j//hBaTsDxa46PgpkviV4aTGHJUmJ93Opue35vMuTeNh3bQT6N/XYvLq7Xm9to4MtTme 0DUkfbKDNOlgnAT8pToyBOqupnsJeTkhyrjvq3BoG8c5PyfhKSSnIuEipL3OC54Z65mU ZiAxmeqTqQx9VSXmupDXSM3S5hPR/hCAlRHySAao1s8Sj2hg9L67fMe1LCLSxIrRfL3K D+MQ==
X-Gm-Message-State: AIVw110CFq2hFrNHcemZPAirzgZ4C7Nga95v3llUCYIeIMnwUdmNY17s cq525vbGhLE2DCLx
X-Received: by 10.237.33.204 with SMTP id m12mr12745439qtc.249.1500976512504; Tue, 25 Jul 2017 02:55:12 -0700 (PDT)
Received: from macbook-pro-6.w50.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m41sm9905282qtc.78.2017.07.25.02.55.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 02:55:11 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <7E291C54-9C0E-418F-A9A4-AB2FFB1700E6@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5C827A3B-7CE7-4E82-A5AA-910A1702180B"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 25 Jul 2017 05:55:10 -0400
In-Reply-To: <CAL9jLaZrsiGZUPJzT1bZG-K2mTt3wP=x05-_Qp=rRh8uaBjS4g@mail.gmail.com>
Cc: George Michaelson <ggm@algebras.org>, dnsop WG <dnsop@ietf.org>
To: Christopher Morrow <morrowc.lists@gmail.com>
References: <CAKr6gn1mZ7VTfM_wtpFX-G95wg-bWRA_YciZScFvr-YX8eYdWg@mail.gmail.com> <CAPt1N1nutxneiZg1JR90O5vRXVs+0WHvRtHpwCRyn4bXpf6g4A@mail.gmail.com> <CAL9jLaZrsiGZUPJzT1bZG-K2mTt3wP=x05-_Qp=rRh8uaBjS4g@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GZ-M7G_ec5nDErQMHtwPg7thUeE>
Subject: Re: [DNSOP] EDNS0 clientID is a wider-internet question
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jul 2017 09:55:18 -0000

On Jul 24, 2017, at 8:59 PM, Christopher Morrow <morrowc.lists@gmail.com> 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 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 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.

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 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.

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.