Re: [urn] Registration request for urn:eris: namespace
worley@ariadne.com Mon, 18 September 2023 03:31 UTC
Return-Path: <worley@alum.mit.edu>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1027CC151069 for <urn@ietfa.amsl.com>; Sun, 17 Sep 2023 20:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.992
X-Spam-Level:
X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-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=pass (2048-bit key) header.d=comcastmailservice.net
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 D0DdPleH0xFZ for <urn@ietfa.amsl.com>; Sun, 17 Sep 2023 20:31:35 -0700 (PDT)
Received: from resqmta-c1p-023465.sys.comcast.net (resqmta-c1p-023465.sys.comcast.net [96.102.19.37]) (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 2453DC151067 for <urn@ietf.org>; Sun, 17 Sep 2023 20:31:34 -0700 (PDT)
Received: from resomta-c1p-023269.sys.comcast.net ([96.102.18.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resqmta-c1p-023465.sys.comcast.net with ESMTP id i4vYqNJy06CZ0i4x3q0krE; Mon, 18 Sep 2023 03:29:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1695007773; bh=DMW9BJSZltd8K6JOvTN8KZ0VdzkT0KSDCaz5Ju2L0Zs=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=XVS6ej7wXz28nxJRjXtAo5Yzb3uP/vNfhb0Tb1MZ6nB0lJUKoGWf/HmfjD8AkHAGt OUachY32Nma0htmNHGm9nDdhX3bI0TE/mCxcD+rMrQkgatWKlZA+qOJ/U0Sebo0wAj pSQGNA3Vn1fI5KsAVdidELkJGWUGLCMwW1qLfsYcqIuugp63Wf/ZdaqqXQDCxCGxkX lQOEU1w9xe5HzPgDeMEWXDLjF1m3UbzhA5alQBX9geA5vqNs9OMqzt+lbMmr/olgo7 W4gW0JGiIIkHrComgteXuHf1SnNuatLmk5kZ9PubdptBLSOeLtoncwjkGchqeNioiq eW2einujpKJ7Q==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::a299]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-c1p-023269.sys.comcast.net with ESMTPA id i4x2q1YulGKiLi4x3qX3M3; Mon, 18 Sep 2023 03:29:33 +0000
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedviedrudejjedgjedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucenucfjughrpefhvfevufgjshestddttddttddttdenucfhrhhomhepfihorhhlvgihsegrrhhirggunhgvrdgtohhmucdlffgrlhgvucftrdcuhghorhhlvgihmdenucggtffrrghtthgvrhhnpeejteeugeetkeehvefgtdekieejheeftefffedvheeljeekveeuueehjeehleejffenucfkphepvdeitddumeduledvmeegrgdttdemgeeftdemmegrvdelleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehhohgsghhosghlihhnrdgrrhhirggunhgvrdgtohhmpdhinhgvthepvdeitddumeduledvmeegrgdttdemgeeftdemmegrvdelledpmhgrihhlfhhrohhmpeifohhrlhgvhiesrghluhhmrdhmihhtrdgvughupdhnsggprhgtphhtthhopedvpdhrtghpthhtohepvghhmhhrhiesphhoshhtvghordhnvghtpdhrtghpthhtohepuhhrnhesihgvthhfrdhorhhg
X-Xfinity-VMeta: sc=0.00;st=legit
Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 38I3TVeI516336 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 17 Sep 2023 23:29:31 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 38I3TVjP516333; Sun, 17 Sep 2023 23:29:31 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Endo Renberg <ehmry@posteo.net>
Cc: urn@ietf.org
In-Reply-To: <1694856169.lcxe8yiejf.astroid@garbage.none> (ehmry@posteo.net)
Sender: worley@ariadne.com
Date: Sun, 17 Sep 2023 23:29:31 -0400
Message-ID: <87il88rwf8.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/F-W1yrpMOxlir_LbXOcTZFwSCf4>
Subject: Re: [urn] Registration request for urn:eris: namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Sep 2023 03:31:39 -0000
> Namespace Identifier: ERIS > Version: 1 > Date: 2023-09-16 > Registrant: Endo Renberg <ehmry@posteo.net> My overall impression of the Eris proposal is difficult to describe. Perhaps the best term is "experimental", in that there is a lot of important stuff here but further thought and description is needed. In regard to the immediate need, I might suggest assigning an "informal" namespace, e.g., "urn-8", for current usage, and when the practical issues are clarified, to assign a formal namespace. RFC 8141 says that the requirements for an informal namespace are essentially the same as for "formal" namespaces but the practice seems to be to apply much less strict examination to their definition. Some questions that I have are the following. They are not listed in any significant order. 1. To what degree are Eris URNs being used in practice? Ideally, there are systems working on a day-to-day basis that use them. The impression I get is that this proposal is a well-worked-out part of a generic distributed system that does not yet exist. 2. The nature of Eris URNs is unusual, in that while they do not provide direct information for locating a resource, they are only used to locate resources, that is, they have no particular value except when one is retrieving a resource. I'd like to suggest that the authors back away from looking at the URNs solely as the inputs and outputs of particular algorithms and also look at them as abstract identifiers. One idealization is that the NSS can be divided into two parts, one that identifies/names the block of information and one that is used to decode that block of information. I'm pretty sure that isn't what's happening here, as the the "convergence secret" concept forbids always having the same resource content generate the same text in part of the URN. But I'd like to see a description of the URNs and how they and their parts behave, from the point of view of a set of abstract identifiers. Ideally, this sort of abstract discussion of Eris URNs would be fairly simple and clear; simplicity and clarity of abstractions is a sign that implementation difficulties are less likely to arise. 3. The Eris scheme has a fixed set of cryptographic algorithms and there is no mechanism to update with newer ones. How much are you prepared to wager that these particular algorithms will be useful in practice 50 years from now? I would recommend adding a versioning element in the URN, perhaps something as simple as putting a fixed "A" after "urn:eris:" and before the 106-character NSS. The "A" could be replaced with other BASE32 characters if additional URN formats are needed to support additional algorithms. 4. The proposal seems to be ambiguous about security. All of the content is encrypted with keys of significant length and the text declares "Intermediary peers, who are storing and transporting encoded blocks without access to a read capability, can claim that decrypting encoded content is infeasible for them." And yet the test also says "Confidentiality is not an objective of ERIS and ERIS SHOULD NOT be used to ensure that content is kept secret from an adversary." Which is intended? If the scheme *appears* to expend effort to provide privacy, the scheme should be designed to provide privacy. 5. Presumably the intended retrieval mechanism is to use a URN as input to some process to identify servers that might contain the resource, followed by delivering the URN to those servers, which use it to locate the resource. What assurance is there that the structure of the URN is suitable for this? I think that the desired property is that any initial substring of the NSS is expected to be uniformly distributed over the space of all such BASE32 strings, and probably this is the only useful property that can be specified for this sort of identifier. But these considerations should be described explicitly (including so that the authors can assure themselves that a location process can be implemented). Dale
- Re: [urn] Registration request for urn:eris: name… worley
- [urn] Registration request for urn:eris: namespace Endo Renberg
- Re: [urn] Registration request for urn:eris: name… Peter Saint-Andre
- Re: [urn] Registration request for urn:eris: name… worley
- Re: [urn] Registration request for urn:eris: name… Peter Saint-Andre
- Re: [urn] Registration request for urn:eris: name… Endo Renberg
- Re: [urn] Registration request for urn:eris: name… Peter Saint-Andre
- Re: [urn] Registration request for urn:eris: name… worley
- Re: [urn] Registration request for urn:eris: name… worley
- Re: [urn] Registration request for urn:eris: name… Peter Saint-Andre
- Re: [urn] Registration request for urn:eris: name… worley
- Re: [urn] Registration request for urn:eris: name… Endo Renberg