#466: extendable Introducer protocol: dictionary-based, signed announcements
------------------------------+---------------------------------------------
Reporter: warner | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: undecided
Component: code-network | Version: 1.1.0
Resolution: | Keywords: introduction
forward-compatibility performance accounting ecdsa pycryptopp
Launchpad Bug: |
------------------------------+---------------------------------------------
Comment (by warner):
Ok, that -ver6 patch is worth reviewing. I think there are a few more
items I
want to add before landing (more tests, mainly), but it's certainly worth
talking about.
This version drops the certchain that was in the previous one: each
announcement is either signed with a single pubkey, or not signed at all.
It
uses an embedded copy of my python-ecdsa library
(https://github.com/warner/python-ecdsa), which is a bit on the slow side,
but still fast enough for announcement/introducer use. It adds code to the
{{{IntroducerClient}}} to add, distribute, and verify signatures, but does
not add any code to the {{{Client}}} or {{{StorageBroker}}} to use those
features: actual UI/tahoe.cfg switches to enable signing or require
signatures is left for a future patch.
The patch creates a new version of the Introducer, as well as its
protocols.
V2 servers (i.e. Introducers) can accept connections from either V1 or V2
clients, and V2 clients can tolerate talking to a V1 server, so all
combinations are covered. Signatures can only be passed from a V2 client,
through a V2 server, off to another V2 client: any V1 components along the
way will lose the signature.
Each announcement is a dictionary with keys to replace everything that was
in
the V1 protocol's tuples. I added some more version information (the full
app-versions dict), which may be too much (especially if you're trying to
be
anonymous).
The quirkiest thing about this scheme is the relationship between FURL
tubids
and ECDSA pubkeys. The Introducer is supposed to recognize multiple
announcements from the same source and let the new one replace the old
one.
When both are V1 tuples with the same tubid in their FURLs, or when both
are
V2 dicts signed by the same pubkey, the relationship is easy. If a client
is
upgraded from V1 to V2 and starts signing its announcements, the V2
announcement won't replace its old V1 announcement. I'm not sure how to
handle this yet.
In addition, we need to think about how/if we want to transition serverids
from being FURL-based to being pubkey-based. Since serverids are baked
into
shares (both via the permuted serverlist and, more directly, by the
Write-Enablers embedded in each mutable share), we can't just casually
change
an existing server's id. For brand-new servers, we could switch to using
the
pubkey as the serverid: this might make non-Foolscap-based share-transport
protocols easier to secure. For old servers with pre-existing shares that
start signing their announcements, we should probably keep using their
tubid
as a serverid, perhaps even after we switch away from foolscap and to some
ECDSA-signature based protocol. But we must validate it: a bad server
could
publish a FURL that they don't actually control, with a tubid that matches
the server they wish to impersonate, knowing that we'll never actually
connect to the FURL and discover the problem. I think the validation
protocol
will involve connecting to the FURL and receiving a copy of the pubkey
back,
to prove that the owner of the FURL really does want to be associated with
that pubkey.
--
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/466#comment:11>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage
_______________________________________________
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
