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

Robert Edmonds <edmonds@mycre.ws> Mon, 24 July 2017 23:44 UTC

Return-Path: <edmonds@mycre.ws>
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 DB758126CB6 for <dnsop@ietfa.amsl.com>; Mon, 24 Jul 2017 16:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 h5Zksth1mdu7 for <dnsop@ietfa.amsl.com>; Mon, 24 Jul 2017 16:44:17 -0700 (PDT)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BCC120724 for <dnsop@ietf.org>; Mon, 24 Jul 2017 16:44:17 -0700 (PDT)
Received: by chase.mycre.ws (Postfix, from userid 1000) id 480F112C1465; Mon, 24 Jul 2017 19:44:16 -0400 (EDT)
Date: Mon, 24 Jul 2017 19:44:16 -0400
From: Robert Edmonds <edmonds@mycre.ws>
To: Ted Lemon <mellon@fugue.com>
Cc: George Michaelson <ggm@algebras.org>, dnsop WG <dnsop@ietf.org>
Message-ID: <20170724234416.pum23jfgvt4lfuf4@mycre.ws>
References: <CAKr6gn1mZ7VTfM_wtpFX-G95wg-bWRA_YciZScFvr-YX8eYdWg@mail.gmail.com> <CAPt1N1nutxneiZg1JR90O5vRXVs+0WHvRtHpwCRyn4bXpf6g4A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPt1N1nutxneiZg1JR90O5vRXVs+0WHvRtHpwCRyn4bXpf6g4A@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-aFgWNhnHBCUsOG-FptZ6d9_Tac>
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: Mon, 24 Jul 2017 23:44:19 -0000

RFC 7217 ("A Method for Generating Semantically Opaque Interface
Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)") is
sort of relevant. From the introduction of that document, which
describes drawbacks of traditional IPv6 SLAAC addresses:

   o  Since the resulting Interface Identifiers are constant across
      networks, the resulting IPv6 addresses can be leveraged to track
      and correlate the activity of a host across multiple networks
      (e.g., track and correlate the activities of a typical client
      connecting to the public Internet from different locations), thus
      negatively affecting the privacy of users.

That drawback translates pretty much directly to the 48-bit MAC
CLIENT-IDENTIFIER variant in draft-tale-dnsop-edns0-clientid.

For the dnsmasq use case, I would guess there's a CPE router/gateway
device involved, in which case the CPE device has a unique
device-specific value burned in (e.g., a WAN-facing MAC address, or
serial number) which could easily be hashed together with the client's
MAC address to produce a stable but opaque identifier specific to the
particular CPE device involved. (That is, if the client device travels
to a different network gatewayed by a CPE device implementing the same
scheme, the identifier generated would be different, because the CPE
device has a different WAN-facing MAC address.) So, the cloud would
still wind up executing the PII -> policy translation, but you take the
'P' out of 'PII', and don't need to store any extra state on the CPE
device.

Ted Lemon 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.
> 
> On Thu, Jul 20, 2017 at 7:00 PM, George Michaelson <ggm@algebras.org> wrote:
> 
> > I probably will not carry the WG with me on this, but I find myself
> > thinking the PII aspect of client-ID makes it a wider-internet
> > question and we might have views as a WG, and promote questions as a
> > WG, but I think the "final call" on this is something which needs more
> > than WG approval.
> >
> > Its a big question. I'd actually welcome adoption on many levels, but
> > that isn't to pre-empt that it goes to WGLC. I think we need to
> > formalize the issues and take them out of the WG for review and
> > discussion.
> >
> > documenting current practice is ok btw, but .. PII.
> >
> > -G
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


-- 
Robert Edmonds