Email list hosting service & mailing list manager

politics etc. (usual top-posting apology) Thomas Lord (31 Jan 2006 18:43 UTC)
Re: politics etc. (usual top-posting apology) Alex Shinn (01 Feb 2006 02:39 UTC)
Re: politics etc. (usual top-posting apology) bear (01 Feb 2006 03:34 UTC)
Re: politics etc. (usual top-posting apology) Alex Shinn (01 Feb 2006 03:57 UTC)
Re: politics etc. (usual top-posting apology) Thomas Lord (01 Feb 2006 05:44 UTC)
Re: politics etc. (usual top-posting apology) Alex Shinn (02 Feb 2006 03:01 UTC)

Re: politics etc. (usual top-posting apology) Alex Shinn 01 Feb 2006 02:39 UTC

On 2/1/06, Thomas Lord <xxxxxx@emf.net> wrote:
>
> In GNU Arch 1.x we have, I claim, decentralized + human-readable +
> secure names.
[...]
> We again start with the idea of an infinite tree-topology
> name-space in which ownership can be assigned (recursively)
> to subtrees:
>
>                 community-sentiment
>                   /      |      \
>                top-level authorities

This is an interesting compromise, but I wouldn't call it secure.  As
soon as you leave something up to "community sentiment," you've lost
security, as there's nothing stopping people from creating their own,
conflicting top-level authorities.  Further the model itself doesn't
guarantee that each top-level authority itself is secure.

But perhaps we're thinking of different meanings of "secure" here.
I'm claiming that to be secure there must be a unique mapping from
name to entity, and this has to be _verifiable_ by automated means.
In terms of Zooko's Triangle, the verification can either be
decentralized (by making the name itself a signature), or
human-readable, by establishing a trusted authority which can answer
"who does this name belong to?" but you can't have both.

By establishing a central authority to register each top-level
authority, and standardizing protocols by which the authorities can
verify names, you can get security.  It's no longer decentralized, but
the work is spread out over a tree of authorities.

You could argue that you don't need secure names, but it's important
not to lie to ourselves and claim something is secure when it isn't.
Most people would be content with a naming convention that simply
avoids unintentional conflicts.  A secure naming system further
resists malicious attacks.

The hypothetical situation posted earlier was exploring what would
happen if we tried to build a trusting, decentralized system of
executing code, and signed and secured everything to the best of our
abilities - with the exception that the module names themselves had no
verification mechanism by their original design.  The conclusion was
of the sort of blinding obviousness that so often gets overlooked when
such systems are designed - if you refer to external modules only by
name, and those names themselves are not secure, then there is room
for attack.  The anecdotal doctor anecdote says "don't do that then."

--
Alex