Re: [Pearg] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

Christian Huitema <huitema@huitema.net> Tue, 03 January 2023 20:14 UTC

Return-Path: <huitema@huitema.net>
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 20FFEC1516EB for <pearg@ietfa.amsl.com>; Tue, 3 Jan 2023 12:14:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8eBlpAqWGIZ for <pearg@ietfa.amsl.com>; Tue, 3 Jan 2023 12:14:38 -0800 (PST)
Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A3AC1516E0 for <pearg@irtf.org>; Tue, 3 Jan 2023 12:14:38 -0800 (PST)
Received: from xse120.mail2web.com ([66.113.196.120] helo=xse.mail2web.com) by mx258.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1pCngB-000GDP-2l for pearg@irtf.org; Tue, 03 Jan 2023 21:14:38 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4NmkTz18JJzBJp for <pearg@irtf.org>; Tue, 3 Jan 2023 12:14:31 -0800 (PST)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1pCng7-0005fJ-0R for pearg@irtf.org; Tue, 03 Jan 2023 12:14:31 -0800
Received: (qmail 5537 invoked from network); 3 Jan 2023 20:14:30 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <phill@hallambaker.com>; 3 Jan 2023 20:14:29 -0000
Message-ID: <f6448bbc-ddc0-2c1e-05a2-990a5a0dc8b6@huitema.net>
Date: Tue, 03 Jan 2023 12:14:30 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
Content-Language: en-US
To: Phillip Hallam-Baker <phill@hallambaker.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "hrpc@irtf.org" <hrpc@irtf.org>, "pearg@irtf.org" <pearg@irtf.org>, saag <saag@ietf.org>
References: <HE1PR0701MB305098F652DBC34E3C40810B89F49@HE1PR0701MB3050.eurprd07.prod.outlook.com> <dc5d3c2c-e110-69f6-c868-9a62d963959f@gmail.com> <CAMm+Lwhy2RtdfYb5Yenw3aURBcE293DDFqiVBgDCWbD5MhunBg@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
In-Reply-To: <CAMm+Lwhy2RtdfYb5Yenw3aURBcE293DDFqiVBgDCWbD5MhunBg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: 66.113.196.120
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yiJCcjRq2hqrD2/ptWXAoffYzfQXcfqmra3dmoHS4ygvNb 7YDZsg9t2RM7OlIasC9WuRWrkPihq53YqAd1ENNqBHtNXu1E6L4+KyOXc4QYanQOD0r6/AaHZiEt dTMtMlia0Lmg/jgHfCNZd+W+PXf6XUk6RrSmTpxXJFCgE5YUPyue9TLOhN8AYRsvkjfngQDCCqjo gBy6Z7Z1H0a6XOEbzDkBvlIN1pUDU5DU5DggD98cjIN3reG9z0FKKQ5m2Qpw7sOVVcM1Xk+Tdz6g /UMvfWqyN3veeFIMJz/vumcqAwMU9kjfE7EFo+kP5riIEUmxU01QhuxnshSbl6nxbLZ35/xY0uvo WBEOfzq3RG28wI7w4vcwqZanLHsZM8r4s5ZjlHoGly8aneNxj+pRyx6DFxVLaXQjMXzVZeSmCuLu +pFVgpT1b21uZVckGp0ccOZtuBWXiK6eoWgQZnNLL6SbpUc7peFeo3eDQNYbhOKhzzgqmaDn5SlD Y9mmtv6e91aWBLor1oCWetcUjeG94V2Xnngi+/6K7F4LawYgjjdRUaTeVLW3pB0Q/PTyowo5Afsw fOPKAOvAAn5TDABj3GV3CFXoGKtafvOtcW/mP16bynTCOInfd76oq4RH5afpA3RRyBl07OVp2D/S 9ogT8aIX6abOyKlLsxs8P4CT3FEuG1ZmgjTdXVjtMOs1jg2a+qKC1AI9a3irbifzymzQYX+PHyw5 mIdmsCjHuAIW6mj9i5U6SkoQArvmwVGu5UXMsnCKuZkMyFBGaEBYeh6pTEjUhZvWUUNwY2GwWTj8 xRE1qX6m+UeFXprlCOm3BAEbJtAT1BYHStA0OogdNtRxnRSLF+XCKxIG9XMEgRDdaWpvCv+zESlk TxdSCNcDfRohcehWBb39uS1TjWG2Inx+Ts2QNOYPIz4ynMa7pZQ4hi/HGtuWeHzx9sLaQmDwvYQn 76e9NXttZBkk6PeFqH6So31P
X-Report-Abuse-To: spam@quarantine14.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/MN4BSbHrIyVz-KSAxVH1XdekgPY>
Subject: Re: [Pearg] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.39
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: Tue, 03 Jan 2023 20:14:40 -0000


On 1/3/2023 12:01 PM, Phillip Hallam-Baker wrote:
> On Tue, Jan 3, 2023 at 2:39 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>> On 03-Jan-23 23:27, John Mattsson wrote:
>>
>>> IP addresses are still not only long-lived trackable identifiers, but
>> they also reveal your location.
>>
>> IP addressing is intrinsically topological, so this is never going to
>> change.
>>
>> (Temporary IPv6 addresses are not long-lived, but they remain topological.)
>>
> Which is an argument for not using IP addresses end-to-end.

It is also the argument behind efforts like Oblivious DNS (RFC 9230) or 
Oblivious HTTP (https://datatracker.ietf.org/wg/ohttp/about/).

As Brian said, IP addresses will always embed some kind of topology, and 
we should always assume that this can identify the location of sending 
and receiving parties, as well as providing strong clues about their 
identity. The end-to-end solution is to "wash" the addresses by going 
through relays, but there is always the risk of relays participating in 
tracking. The "oblivious" approach is to mitigate that by minimizing 
information provided to relays.

So yes, IP addresses leak location. But also, yes, the IETF is doing 
something concrete about that.

-- Christian Huitema