Re: [icnrg] This view on web3has some interesting ties to ICN

"David R. Oran" <daveoran@orandom.net> Mon, 10 January 2022 21:28 UTC

Return-Path: <daveoran@orandom.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FD83A0C42 for <icnrg@ietfa.amsl.com>; Mon, 10 Jan 2022 13:28:56 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 byXpv28lP23b for <icnrg@ietfa.amsl.com>; Mon, 10 Jan 2022 13:28:55 -0800 (PST)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9E53A0C40 for <icnrg@irtf.org>; Mon, 10 Jan 2022 13:28:54 -0800 (PST)
Received: from [192.168.15.242] ([IPv6:2601:184:407f:80cf:8b:7c0b:dbfe:eec8]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 20ALSjIq012740 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Jan 2022 13:28:47 -0800
From: "David R. Oran" <daveoran@orandom.net>
To: Dirk Kutscher <ietf@dkutscher.net>
Cc: icnrg <icnrg@irtf.org>
Date: Mon, 10 Jan 2022 16:28:39 -0500
X-Mailer: MailMate (1.14r5856)
Message-ID: <0BA97ECA-A99D-4594-A8E5-83B02D348539@orandom.net>
In-Reply-To: <08289530-AE53-4797-923D-2E49B1F7F9D8@dkutscher.net>
References: <FDAFD852-1109-4A49-9840-4C76716A8ECA@orandom.net> <08289530-AE53-4797-923D-2E49B1F7F9D8@dkutscher.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_0AA9E2FF-D077-497F-91A1-9B6D81D2EBD6_="; micalg="sha-256"; protocol="application/pkcs7-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/X9eQtqdpjp8YU2LgE699xQuy8J0>
Subject: Re: [icnrg] This view on web3has some interesting ties to ICN
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jan 2022 21:28:57 -0000

Lots to unpack here, but I wanted to react to one particular piece since it seems the basis for a lot of recent optimism about ICN for edge applications, like IoT and localized multi-media such as some AR/VR.

On 10 Jan 2022, at 15:14, Dirk Kutscher wrote:


> Unlike most web3 systems, you can really build autonomous application in local networks, i.e., operate in a decentralized way. Moreover you can build systems accessing named data without location notion at all, not only for files or web objects, but for any kind of data and service.
>
You might be able to build it, but some of the things that rapidly raise themselves as thorny issues are:

- you need to do a “leap of faith” enrollment on every single participant in order to get the local trust root installed. This might be somewhat sidestepped with key pinning to the application code but then:

- how do you install/update the application when the participant enters the local trust zone with no root key or an expired one?

- I’m increasingly convinced that a first order deterrent to this kind of decentralization is the very small number of entities any individual is able to assess trust in. I suspect it’s somewhere between 5 and 25; not thousands or millions. Sure, I don’t want to be forced to trust just one or two financial institutions, or just my national government bureaucracy, or the small set of Google/Microsoft/Amazon/Alibaba, etc. but how to I navigate assessing a giant number of trust roots? It seems at least superficially that web-of-trust approaches should work swimmingly well here, but we have 30 years of abject failure (e.g. PGP/GPG) in getting these adopted and maintained in practice.

- If you find the point above modestly convincing, then current proven and reasonably efficient K-out-of-N keying schemes for enabling modestly-sized trusted intermediary sets, and Byzantine fault tolerant agreement protocols for distributed databases seem quite sufficient for all these use cases.

Nice New Year ICN discussion topic, no?