Re: [urn] Registration request for urn:eris: namespace

[Endo Renberg <[e-mail]>]

Hello Dale,

Sorry for the late reply and the bungled CC to Peter.

Excerpts from Dale R. Worley's message of September 18, 2023 4:29 am:
> 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.

That is an understandable impression, the ERIS specification is fixed
at this point but is incomplete in regards to resolution and at this point
is only used in experimental applications.

> 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.

During development the namespaces "urn:erisx1", "urn:erisx2", "urn:erisxN"
were used but in retrospect this should have been done within an informal
namespace.

> 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.

There are a number of experimental projects that use ERIS. A subset of
those rely on the URN representation of read capabilities. If we had a
robust distribution method at the time the spec was finalized we would
have still avoided mentioning it as we want to be careful to define the
content encoding and identifiers without being biased towards any
distribution medium.

> 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.

We have what we call "read capabilities" as our abstract identifiers and
use the URN for exchanging these in a way that is compatible with systems
that use URIs.

> 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.

There are essentially four fields in the URN text, a chunk-size byte, a
tree depth byte, a thirty-two byte encryption key, and a thirty-two byte
chunk hash. These are packed together without any visual seperators
but this can be described in the registration request.

It is certainly possible to generate the same URN twice if the null
convergence-secret is used. For security reasons we encourage implementors
not to make this the default, but in practice the deterministic URNs are
most common.

> 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.

This was discussed during drafting and a security review but the consensus
was that extensibility is a non-feature in light of downgrade attacks. The
hash and crypto key stream algorithms are similar enough that we consider
the crypt-analysis-surface there is quite small. If crypto breaks we would
hope that the ERIS be abandoned and a replacement would  have a completely
different name.

> 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.

The proposal is designed to provide privacy but is intentionally ambiguous
about security. One can define security models where ERIS is sufficient or
insufficent for provided privacy, and this contigent on what distribution
method is used to exchange chunks. We let application designers decide
whether or not ERIS provides the security features they need.


> 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).

Correct, the URN only describes the bare minimum for reconstructing some
content independent of location.


Thank you Dale and Peter for the thoughtful early review, I will resubmit
in the next few days.

E.