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

Eliot Lear <lear@lear.ch> Wed, 04 January 2023 08:51 UTC

Return-Path: <lear@lear.ch>
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 EB504C14F5E0 for <pearg@ietfa.amsl.com>; Wed, 4 Jan 2023 00:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.888
X-Spam-Level:
X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 oEeGhPHGmQFU for <pearg@ietfa.amsl.com>; Wed, 4 Jan 2023 00:51:51 -0800 (PST)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [IPv6:2a00:bd80:aa::2]) (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 685CEC14CF1A for <pearg@irtf.org>; Wed, 4 Jan 2023 00:51:50 -0800 (PST)
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1672822306; bh=YHaBh3ivxonDBS4bejmds/nyUA/a/1pE1IBo1Nrd6uo=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=f442BG8TFEmco0e3hqh+BGQAtivyuI5//LTodqb4TEQo7PtLExktKtgtToclqdFPt VrJdc1n4iH/68U8WJ8gt+OXp3qWP++hAhXPcApYUCCU7B2E2wi9nUsG9r/9Udlg6Hr Vo+q4tBHTQKfXc4W+rUWqlrfYrvuUzeF5Q9GAlWU=
Received: from [192.168.0.222] (77-58-144-232.dclient.hispeed.ch [77.58.144.232]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 3048pjX9740539 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 4 Jan 2023 09:51:45 +0100
Message-ID: <bf81f001-3de1-0c05-bbbb-eda13adb4ddf@lear.ch>
Date: Wed, 04 Jan 2023 09:51:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
Content-Language: en-US
To: Stewart Bryant <stewart.bryant@gmail.com>, Dino Farinacci <farinacci@gmail.com>
Cc: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, pearg@irtf.org
References: <9C9FAB23-D95D-4BB6-820C-95DA8018451B@gmail.com> <9E792EAB-29DF-4A7F-8F6B-BD5BF8041167@gmail.com>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <9E792EAB-29DF-4A7F-8F6B-BD5BF8041167@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------K84XBaEb9RZOqrxVN55m5XuN"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/tRAk5JOyPGZo-YhL8h6E030AIzM>
Subject: Re: [Pearg] [saag] 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: Wed, 04 Jan 2023 08:51:56 -0000

I'm reducing this down to pearg.  Blasting so many lists seems a bit much.

Someone somewhere needs a stable identifier, but whether that identifier 
needs to be at L3 depends on the circumstances.  For well known 
servers... well, they're well known, so hiding an L3 address buys you 
what?  For less well known stuff, the mapping of an ephemeral L3 address 
to a stable identifier may not require standardization at the L3 layer.  
Having a rendezvous registration service of some form even at the 
application layer may be sufficient.  What is necessary, as always, is 
the means to communicate with the device behind NATs/firewalls, etc.  
The authorization model for that may require a tell in order to avoid 
trumboning.  That may or may not be necessary, depending on how 
sensitive an application is to latency/jitter.

It could be that the OS signaling for changes to the mapping and the 
means by which the mapping is communicated within applications *could* 
be standardized.  That's akin to TURN and STUN, right?

Eliot

On 04.01.23 09:05, Stewart Bryant wrote:
> For all end to end communications the routing system needs to know how to deliver the packet. Obscuring the mapping between the address and the location moves the anonymisation problem from the data plane to the routing plane. This makes life harder for the observer, but I am not sure that it makes it sufficiently hard as to be worth the cost. One advantage of the topological association of addresses is the intrinsic address aggregation property which both reduces routing traffic overhead and speeds up convergence.
>
> Stewart
>
> Sent from my iPad
>
>> On 3 Jan 2023, at 22:29, Dino Farinacci<farinacci@gmail.com>  wrote:
>>
>> EIDs are not topological. We have all known this for a very long time. We can make them ephemeral as well, we can make them cryptographic.
>>
>> Dino
>>
>>> On Jan 3, 2023, at 11:38 AM, 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.)
>>>
>>>   Brian
>>>
>>> _______________________________________________
>>> saag mailing list
>>> saag@ietf.org
>>> https://www.ietf.org/mailman/listinfo/saag
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>