Re: [Pearg] Fwd: [art] Side meeting for IP address privacy on the web

Fernando Gont <fgont@si6networks.com> Mon, 24 February 2020 02:45 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A373A0827 for <pearg@ietfa.amsl.com>; Sun, 23 Feb 2020 18:45:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.356
X-Spam-Level:
X-Spam-Status: No, score=-0.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wBzWEeMEQZjz for <pearg@ietfa.amsl.com>; Sun, 23 Feb 2020 18:45:54 -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 A8CF13A0828 for <pearg@irtf.org>; Sun, 23 Feb 2020 18:45:53 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (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 8288682DF1; Mon, 24 Feb 2020 03:45:47 +0100 (CET)
To: Allison Mankin <allison.mankin@gmail.com>, "pearg@irtf.org" <pearg@irtf.org>
References: <CABQTWrkzsE=KxLTNS5RBmgi2rkj2GJDCWmEG=XB6TMJBt7HZng@mail.gmail.com> <CAP8yD=tiCwxOUu5ojiNL3b1t1j7G4zDkO3J9ypwWTi0NNYgmWA@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Cc: art@ietf.org
Message-ID: <7dad383b-fe17-85dd-609f-22db7f4efa55@si6networks.com>
Date: Sun, 23 Feb 2020 12:44:46 -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: <CAP8yD=tiCwxOUu5ojiNL3b1t1j7G4zDkO3J9ypwWTi0NNYgmWA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/GBgcuhw4xRDZVtXb52n6Rp3qxhE>
Subject: Re: [Pearg] Fwd: [art] Side meeting for IP address privacy on the web
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2020 02:45:56 -0000

Folks,

Unfortunately I will not be attending the next IETF meeting, but I felt 
like posting a few comments on the topic.

Some of us have done a fair share of work in the area of "address 
privacy", among others, please see:

* RFC7217/RFC8064: which replaces traditional stable IPv6 addresses with
                    something more sensible (from a privacy point of
                    view)

* draft-ietf-6man-rfc4941bis: A revision of RFC4941 to fix a number of
                    flaws in it.

* RFC7721: Privacy analysis of IPv6 addresses.

* draft-gont-6man-address-usage-recommendations: A document that,
                    among other things identifies gaps that prevent us
                    from doing more appropriate usage of IPv6 addresses.


They try to address as much of the problem as is "addressable": Modulo 
the IID part of an address (which may unnecessarily leak information), 
all the topologically-dependent bit of an address are simply serving 
their purpose. Put another way, an address is a topologically-dependent 
identifier. So it *will* leak the position of the node in the network 
topology (that's why you use adressses in the first place, such that the 
network knows how to get packets back to you!).


The browser "solutions" listed below are not really solutions: e.g., a 
VPN simply adds one extra layer of indirection, and essentially choose a 
different point in the network that gets to see all of the users' 
traffic, and is able to track users in a very easy way. dVPN would be, 
in a way, something along the lines of Tor? -- If so, why not Tor?

As with DoH, relying on a single party to behave nicely, based on the 
(questionable) assumption that some party (in this case the local ISP) 
is evil, while another is just nice (in this case the VPN concentrator, 
or analogous for the browser extension) leads to, IMO, a more scary 
scary situation where a single entity could potentially go rogue, or be 
hacked, affecting the privacy of many more users.

As with e.g. DoH, you don't really get privacy, but rather get to pick 
how gets to peak at your traffic.

This is an important message to state clearly... and hopefully an 
argument such that browsers *never* enable this king of thing by 
default, as was the case with DoH in some cases.

Thanks!

Cheers,
Fernando




On 21/2/20 00:33, Allison Mankin wrote:
> Hi PEARG,
> 
> This is likely of interest to many of you.
> 
> See you at IETF 107.
> 
> ---------- Forwarded message ---------
> From: *Paul Jensen* <pauljensen=40google.com@dmarc.ietf.org 
> <mailto:40google.com@dmarc.ietf.org>>
> Date: Fri, Feb 14, 2020 at 14:58
> Subject: [art] Side meeting for IP address privacy on the web
> To: <art@ietf.org <mailto:art@ietf.org>>
> 
> 
> I intend on holding a side meeting at IETF 107 to talk about IP address 
> privacy on the web.  As many browsers work to combat fingerprinting on 
> the web, a user's IP address, the single most identifying 
> fingerprintable surface, remains largely unprotected. Various browsers 
> have acknowledged the fingerprintability of IP addresses or have 
> proposed a solution: Chrome (https://github.com/bslassey/ip-blindness), 
> Firefox 
> (https://blog.mozilla.org/blog/2019/09/10/firefoxs-test-pilot-program-returns-with-firefox-private-network-beta/), 
> Safari (https://webkit.org/tracking-prevention-policy/), Brave 
> (https://brave.com/vpn0-a-privacy-preserving-distributed-virtual-private-network/).  
> I'd like to hold a side meeting on this topic to start the conversation 
> around IP address privacy on the web.  Specifically with the goal of 
> preventing IP from being used as a tracking vector, but trying to do so 
> without breaking beneficial use cases such as DoS, fraud, spam and other 
> abuse prevention.  Agenda might look something like this:
>>
>>   * What IP is used for
>>       o Spam, abuse, fraud, DoS protection
>>       o Geo IP
>>       o Ad targeting
>>       o others?
>>   * Privacy research
>>       o IP reidentification
>>       o IP fingerprinting
>>   * Proposals for IP blindness
>>       o VPN0
>>       o FPN
>>       o Willful IP Blindness
> If you're interested in attending please let me know which days you have 
> conflicting obligations in the morning slot.
> 
> Paul
> _______________________________________________
> art mailing list
> art@ietf.org <mailto:art@ietf.org>
> https://www.ietf.org/mailman/listinfo/art
> 


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