Re: Address privacy (was: Re: RFC4941bis: consequences of many addresses for the network)

Fernando Gont <fgont@si6networks.com> Tue, 28 January 2020 01:42 UTC

Return-Path: <fgont@si6networks.com>
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 C278F3A0829 for <ipv6@ietfa.amsl.com>; Mon, 27 Jan 2020 17:42:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nfH0Vu3dwiig for <ipv6@ietfa.amsl.com>; Mon, 27 Jan 2020 17:42:43 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47B03A082A for <ipv6@ietf.org>; Mon, 27 Jan 2020 17:42:43 -0800 (PST)
Received: from [192.168.100.103] (unknown [186.183.48.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id F304886B99; Tue, 28 Jan 2020 02:36:28 +0100 (CET)
Subject: Re: Address privacy (was: Re: RFC4941bis: consequences of many addresses for the network)
To: Ole Troan <otroan@employees.org>, Christian Huitema <huitema@huitema.net>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
References: <6f2a8e5a-a4f6-219b-d7c8-ba79ed257785@huitema.net> <36CC44E1-D74F-4C76-B9FD-E56A81FC9BD6@employees.org>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <7ef27bc1-9cbe-2919-5c6f-0e344656429f@si6networks.com>
Date: Mon, 27 Jan 2020 20:23:38 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <36CC44E1-D74F-4C76-B9FD-E56A81FC9BD6@employees.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/nmRqlNEoS33TlfxpU1B7mxvMfe4>
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 01:42:46 -0000

On 26/1/20 04:13, Ole Troan wrote:
> 
> 
>> On 26 Jan 2020, at 06:41, Christian Huitema <huitema@huitema.net> wrote:
>>
>> On 1/25/2020 4:18 PM, Jared Mauch wrote:
>>
>>> I'm not convinced that I get more privacy by using the privacy
>>> addresses and more than encoding my emails with rot13.
>>>
>>> The industry has far more advanced ways to fingerprint users. The data
>>> done by https://amiunique.org/ folks as well as others make it clear
>>> that IP addresses aren't the means of tracking that I believe the
>>> concerns that introduced privacy addresses were attempting to solve.
>>
>> Yes, there are many leaks. That not a reason to not plug our own leak,
>> i.e. the use of IP addresses as unique identifiers. As the web leaks are
>> progressively plugged by privacy oriented browsers or by fingerprint
>> blocking add-ons, the importance of address privacy increases.
> 
> I do wonder if rotating the iid is significantly better than a stable per-link 7217 iid.

Temporary addresses can be better for mitigating network activity 
correlation over time. -- whether "significantly better"... that'd be 
hard to gauge. (particularly when the defautl preferred lifetimes are 
not so agressive).


One way in which temporary addresses could be a clear improvement would 
be if they could only be employed for outging communications. For 
connection-oriented protocols, that would be easy, straightforward, and 
would have clear benefits.

For UDP-based protocols, not so easy, if at all possible.


> 
> Isn’t the first thing an application does to use the temporary address to authenticate with a service, that then turns around and sells the information abo the user to address mapping on the open market?

That links an identity with an address. Then, as long as you reuse the 
address, you link that new activity, with your identity -- that's the 
case for "ephemeral addresses". -- so that you can break the link 
between your identity (which you leaked when you auth'ed, and your new 
activities).


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492