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

Paul Wouters <paul@nohats.ca> Tue, 25 July 2017 07:23 UTC

Return-Path: <paul@nohats.ca>
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 022D4131822 for <dnsop@ietfa.amsl.com>; Tue, 25 Jul 2017 00:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 nhmRarE89oqc for <dnsop@ietfa.amsl.com>; Tue, 25 Jul 2017 00:23:27 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 162A413188F for <dnsop@ietf.org>; Tue, 25 Jul 2017 00:23:27 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3xGqTl34x1z3Nl; Tue, 25 Jul 2017 09:23:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1500967403; bh=ztFI3y0IEcRRFMcXmMn4YPv91l5DdfxYKNU8GjtbIEQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=nKMqxirOUA094CXTP3d2rDOSwNb4ds+2ON3jMk1AsE+pAnOvWA0GcaCuqJ4Vwi/ND Sgq+udopEA+qe0N0GMSbtMiMt2N7c83ge2dDZ5KRIevjgW7Z84j4i1e2sykqziAp8+ kq5K5q6yDm/dSTQy8xSnVUscOZH0d0+8gGQ2j1NI=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cpNSttTAncWI; Tue, 25 Jul 2017 09:23:20 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 25 Jul 2017 09:23:20 +0200 (CEST)
Received: from [10.0.1.185] (unknown [85.93.125.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 89F9630AFAA; Tue, 25 Jul 2017 03:23:19 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 89F9630AFAA
Content-Type: multipart/alternative; boundary="Apple-Mail-F8C906EF-94F0-4091-80F0-4A8D56E0A601"
Mime-Version: 1.0 (1.0)
From: Paul Wouters <paul@nohats.ca>
X-Mailer: iPhone Mail (14F89)
In-Reply-To: <CAL9jLaZrsiGZUPJzT1bZG-K2mTt3wP=x05-_Qp=rRh8uaBjS4g@mail.gmail.com>
Date: Tue, 25 Jul 2017 09:23:16 +0200
Cc: Ted Lemon <mellon@fugue.com>, dnsop WG <dnsop@ietf.org>, George Michaelson <ggm@algebras.org>
Content-Transfer-Encoding: 7bit
Message-Id: <5D73941C-B108-4A14-AEE5-7A28BCA94373@nohats.ca>
References: <CAKr6gn1mZ7VTfM_wtpFX-G95wg-bWRA_YciZScFvr-YX8eYdWg@mail.gmail.com> <CAPt1N1nutxneiZg1JR90O5vRXVs+0WHvRtHpwCRyn4bXpf6g4A@mail.gmail.com> <CAL9jLaZrsiGZUPJzT1bZG-K2mTt3wP=x05-_Qp=rRh8uaBjS4g@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VDfq3MfM-UBH8K7wE6r21-1nHhg>
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 07:23:30 -0000

And then there are mobile phones with wifi and LTE tracking, already massively abused by AP's and companies like Apple are randomising macs.

This draft is good for the ad business, not good for the enduser.

Paul

Sent from my iPhone

> On Jul 25, 2017, at 02:59, Christopher Morrow <morrowc.lists@gmail.com> wrote:
> 
> 
> 
>> On Thu, Jul 20, 2017 at 1:54 PM, Ted Lemon <mellon@fugue.com> wrote:
>> It would be nice if there were an RFC to point to that used a method that didn't include PII.   For the use cases of which I am ware, there is no need to identify individual devices: only policies.   What's lacking is a way to do this in the home router, so the PII winds up getting exported to the cloud not because that's necessary to accomplish the filtering but because it's the only available place where the translation from PII->policy can be done in practice.   Unfortunately, solving _that_ problem is definitely out of scope for DNSOP.
>> 
> isn't the query path here: (largely)
>   client  -> cpe-router -> provider-cache-resolver -> auth-dns
> 
> 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.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop