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

Eliot Lear <lear@lear.ch> Wed, 04 January 2023 20:09 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 11DEEC14F74E for <pearg@ietfa.amsl.com>; Wed, 4 Jan 2023 12:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.887
X-Spam-Level:
X-Spam-Status: No, score=-0.887 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_BLOCKED=0.001, 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 zviDXBX4Edlv for <pearg@ietfa.amsl.com>; Wed, 4 Jan 2023 12:09:09 -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 96415C14CE31 for <pearg@irtf.org>; Wed, 4 Jan 2023 12:09:09 -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=1672862937; bh=2j/YocXzW5816MUxUbDGovFU5daQpnGAjRnkjzH3yU8=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=fkEgZc6EPsTjq9st2Nmq5BkBASJzCvKUSXF4lp15bVnVG7cIOrHd6DNImLPaGmgsz F5TV5f0lDEpFktZqME8Fl5ADT2gWvY39HvN0gvpHnJ7FJHoD9gLh/b37lCaTAWlp7q PW3Xi7azFjo9fkeFwD/HDtE4YPu40D3XdaxOW0XI=
Received: from [IPV6:2001:420:c0f8:1004::de] ([IPv6:2001:420:c0f8:1004:0:0:0:de]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 304K8tux756710 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 4 Jan 2023 21:08:57 +0100
Content-Type: multipart/alternative; boundary="------------ILhAFW9zBCjiS8Fj4D20B6wA"
Message-ID: <a42ec124-9953-5bf5-c31d-6a274c8836dc@lear.ch>
Date: Wed, 04 Jan 2023 21:08:53 +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: Christian Huitema <huitema@huitema.net>, 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> <bf81f001-3de1-0c05-bbbb-eda13adb4ddf@lear.ch> <b80abf6b-23fe-2fa8-a435-08d78be0de23@huitema.net>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <b80abf6b-23fe-2fa8-a435-08d78be0de23@huitema.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/fyfgEubPlGRtgNSn3hKAbMxK82Y>
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 20:09:14 -0000

On 04.01.23 20:53, Christian Huitema wrote:
> The problem is that the IP address is linked to the server and user 
> identity. Tracking the source and destination pair allows on path 
> entities to check which user contacts what server. It also allows 
> servers to check the identity of their client and their location. 
> Servers may have other ways to check identity such as cookies or 
> client login, but the client IP address provides location information 
> on top of that.

The thrust of my point is whether we need to make prohibitively 
expensive L3 changes.  OHTTP and ODNS demonstrate at a *technical level* 
that we do not.  But see below.


>
> The big issue behind that are of course performance and economics. 
> Using such relays degrades performance somewhat, if only because of 
> double or triple encryption: will the users accept that reduced 
> performance? And then, operating relays has a cost. Who will pay for 
> that? If the users do pay for that, how does the users pay without 
> disclosing their identities to the relays, and thus enable monitoring? 
> If the users do not pay, how can we sure of the intentions of whoever 
> is paying for the relays?

However you slice this, whether at L3 or above, you will have this 
problem.  This is true even with LISP, because the XTR requires an 
mapping function, and those things don't run for free either.  So it's 
probably good to distill the principles here, as you have done.  Many of 
the performance and cost issues are the same.

Eliot