[tahoe-lafs-trac-stream] [tahoe-lafs] #466: extendable Introducer protocol: dictionary-based, signed announcements

[tahoe-lafs]

#466: extendable Introducer protocol: dictionary-based, signed announcements
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:  warner
         Type:           |     Status:  closed
  enhancement            |  Milestone:  1.10.0
     Priority:  major    |    Version:  1.1.0
    Component:  code-    |   Keywords:  introduction forward-compatibility
  network                |  performance accounting ecdsa pycryptopp
   Resolution:  fixed    |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by warner):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Ok, time to close this one out. The code landed a while ago, and things
 look
 stable. A few more notes about the final protocol that we settled on (and
 how it
 differs from the big explanation in comment:17) :

 * announcements contain separate fields for the different uses of a
 "server
   id". This turned out to work better than having a "serverid-type"
 marker.
  * {{{anonymous-storage-FURL}}}: points at the foolscap object that
 provides
    non-Accounting-based storage service, using the same protocol we've
 been
    using for years. It has the "anonymous-" prefix to distinguish it from
 the
    non-anonymous thing that Accounting (#666) will provide. When a server
    requires accounting-based connections, its announcement will omit
    {{{anonymous-storage-FURL}}}.
  * {{{permutation-seed-base32}}}: tells clients where to place this server
 in
    the permuted ring, for share-placement purposes. The server gets to
 decide
    this placement independently of its serverid or tubid (this is
 marginally
    more power than they had before, but we decided it was safe). New
 servers
    use the public-key -based serverid for this. Old servers (those which
 have
    published shares under their tubid) keep using their tubid for this, to
    maintain stability (clients keep looking for shares in the same old
    place). The code in {{{client.py:_init_permutation_seed()}}} holds this
    "Am I old or new" logic.
 * the {{{IntroducerClient}}} which receives these announcements produces
 an
   {{{IServer}}} object, specifically a
   {{{allmydata.storage_client.NativeStorageServer}}}, which offers methods
   that client code can use to figure out how to talk to the server.
  * {{{get_permutation_seed()}}}: maps directly to {{{permutation-seed-
 base32}}}
  * {{{get_lease_seed()}}} and {{{get_foolscap_write_enabler_seed()}}}:
 both
    return the *tubid*, never the pubkey-based serverid, because these are
    used for shared-secret authorization of
    add-lease/remove-lease/modify-share operations, and shared-secrets are
 only
    safe to inside a channel that's tied to those secrets. Since these
    operations are closely tied to Foolscap, it's ok to leave them using
 the
    tubid. When we move to a non-Foolscap transport layer, we'll need to
 use
    different authorization mechanisms for leases and write-enablers, and
    these will go away.
 * the pubkey-based serverid will be used for all future
   explicit-server-selection and Accounting needs, never the tubid
 * the code uses ed25519 signatures (from pycryptopp), not python-ecdsa.
 These
   signatures are shorter, faster, and more secure.
 * serverids have "v0-" version prefixes, as do the signatures. The pubkey
 and
   signatures are sent as base32-encoded strings, to make non-binary-safe
   transports easier to accomodate. When presenting serverids to users, the
   v0- prefix is removed.
 * announcements are JSONable dictionaries with unicode fields. The
 signature
   is computed over its UTF-8 encoding.
 * the new protocol is enabled by default. As soon as you start a node with
   the new code, it will generate a new key and start using it.
 * a copy of the old (V1) introducer client+server is retained in
   src/allmydata/introducer/old.py for testing purposes. Once we're no
 longer
   concerned with maintaining compatibility with V1 introducers or clients,
 we
   can remove it.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/466#comment:33>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage