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

[tahoe-lafs]

#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