Re: Address privacy

otroan@employees.org Tue, 28 January 2020 20:09 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EAE1200B3 for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 12:09:56 -0800 (PST)
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, SPF_HELO_NONE=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 tI_aWC_DsWnS for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 12:09:55 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5EE120099 for <ipv6@ietf.org>; Tue, 28 Jan 2020 12:09:55 -0800 (PST)
Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 529084E11ADE; Tue, 28 Jan 2020 20:09:54 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 9DDF92A4F31C; Tue, 28 Jan 2020 21:09:51 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Subject: Re: Address privacy
From: otroan@employees.org
In-Reply-To: <CALx6S36DsttXx-7UWL=iZkGuKG_yNKdADFB5zo87wu2coz8HcQ@mail.gmail.com>
Date: Tue, 28 Jan 2020 21:09:51 +0100
Cc: Nick Hilliard <nick@foobar.org>, Fernando Gont <fgont@si6networks.com>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C6E767BC-BB0F-4B47-8DEB-CD04A6EF7D8C@employees.org>
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <MN2PR11MB3565330989D411525D30B90DD80F0@MN2PR11MB3565.namprd11.prod.outlook.com> <80207E17-AE8E-4D19-B516-D2E6AB70721E@employees.org> <8D5610EA-49D3-483E-BB7A-67D67BC89346@jisc.ac.uk> <DE7B0688-230F-4A5C-8E24-9EAED9FD9FEB@puck.nether.net> <CAO42Z2zXwVnzemRqyqy78czpHjZm0nhkCJgVrx=-fmt+C6MnSA@mail.gmail.com> <1962.1579823388@localhost> <f83ab037-9125-bb74-dbac-68850aeb1020@huitema.net> <CBB23ABE-A7A3-4208-873C-E47EE063E34B@fugue.com> <11855.1579980079@localhost> <CALx6S36V_VjaxhELYcsgDYLWsCkj20p6gtiY9T9Q=9-9Oibyjw@mail.gmail.com> <32626.1580060558@localhost> <CALx6S37prWACD0jv9c-XHD-JtPqZAcgeT2Ax0EZHkiQaDR4t=g@mail.gmail.com> <419b7c7a-e364-7951-5a44-6c39e1da65fb@joelhalpern.com> <CALx6S36802oDaEgojAPq2c6hM_s1BayidXPh1Sc6RZmZa9UHpQ@mail.gmail.com> <6c5ba72d-9289-90ba-a1c9-2307ed29a4da@foobar.org> <a98bf2ab-32e7-459b-14d2-5e0e1c65a229@si6networks.com> <CALx6S36J5TPnXJQyMW2NUbQV6KL_oqUQ01m+BEzBJ+xcHpmQWw@mail.gmail.com> <d763dc26-57bb-c67d-f727-617a6b52d813@foobar.org> <CALx6S36DsttXx-7UWL=iZkGuKG_yNKdADFB5zo87wu2coz8HcQ@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VYnWYgv57Ih_yllcgkQJKpLwEp4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2020 20:09:57 -0000

Tom,

> The problem isn't in identification for apps, it's that the fact that
> the logs created by the app correlate user identity with an IP
> address. Given that correlation, the log could conceivably be used to
> identify participants in completely unrelated communications. Using IP
> addresses to identify individuals involved in communications does
> happen, there are a number of instances noted on the web particularly
> in law enforcement.

is your concern about correlation done by a man in the middle?
or is it the end-points? The operators of those end-points have built an enormous marketplace to trade this information behind your back. temporary addresses will not help against surveillance capitalism.

Temporary addresses doesn't in it's default setting solve the problem of correlation either.
Or should users ensure that they used services that shouldn't be correlated on different days? ;-)
And ensure that they never tainted an address by using it for authentication somewhere.

7217 iids and temporary addresses have the same privacy properties, if you look in table 1 in 7721.
separated by the address lifetime.

A natural consequence of this is that to protect against correlation at layer 3 (all the other tracking would still happen) you need a new address per connection. with a lifetime equal to the connection lifetime.
The network's response to that is likely to assign a static /64 to each host. So now, you can correlate on the prefix instead.

“Addressing can follow topology or topology can follow addressing; choose one” – Y. Rekhter

Ole