[tahoe-dev] #466 (signed-introducer-announcements) landed!
warner at lothar.com
Wed Mar 14 20:06:37 UTC 2012
Thanks to Zooko's hard work in getting pycryptopp-0.6.0.(mumble)
released yesterday, I was finally able to land the #466
signed-introducer code last night. What does this mean for users?
* tahoe now depends upon the new pycryptopp: next time you update,
you'll need to do 'setup.py build' so it will pick up 0.6.0
* the first time your node wakes up with the new code, it will create a
NODEDIR/private/server.privkey file, containing the new Ed25519
private signing key. This is a binary file, not meant for copy/paste
or human interaction.
* server IDs are changing. The old (foolscap-based) IDs look like
"rkybwv7hpuwpnyqhwjz43v727orr7fqd". Once everything is upgraded, the
Welcome page will show new server IDs that look like
"v0-fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq". (the old
ones are a SHA1 hash of the tub's public SSL certificate, the new ones
are an Ed25519 public verifying key)
Internally, this opens up the door for a bunch of stuff:
* Introducer announcements are now extensible dictionaries, instead of
fixed-size tuples. This allows servers to cleanly advertise new
services, and include additional metadata like how much space they
have available. This will be used by the upcoming Accounting work to
advertise an alternate storage-server object from which per-account
connections can be obtained. #666
* Announcements are signed, which means the Introducer doesn't get to
modify the metadata, reducing its authority a little bit. This gets us
one step closer to having a distributed introduction mechanism (the
signed announcements can simply be flooded, without worrying about
what the other nodes might do to them in transit). #68
* Server nodes are known by their Ed25519 public verifying key, rather
than by their Foolscap SSL TubID. This enables secure non-SSL
messaging (sign a request instead of sending unsigned requests over a
validated-SSL connection), so we can switch from Foolscap to e.g. HTTP
for share transport, which should make the Tahoe protocol easier to
port to other languages (Foolscap offers more features than we really
need, and its need to check the SSL certificate is an implementation
* Clients can securely reference a server by its pubkey, which will be
the basis for explicit "which servers am I willing to use"
configuration. #467, #295
What about compatibility? All combinations of V1/V2 client/introducer
should work as expected:
* new (V2) clients can talk to old (V1) Introducers just fine: they'll
detect the lack of V2 methods and talk down to the introducer (sending
it unsigned V1-format tuples instead of signed V2-format
* old V1 clients can talk to new V2 introducers: they send announcements
to the old method name, the Introducer will upgrade the tuples to
dictionaries (unsigned, of course) for distribution to V2 clients, and
distributes the original tuple to V1 clients
* new V2 Introducers can talk to old V1 clients just fine: the client
will subscribe with the old V1 method, causing the Introducer to
downgrade new-style announcements for the V1 client
* V1 clients always get tuples, V2 clients always get dictionaries.
*Signed* announcements will only happen when all three participants
(announcing client, Introducer, subscribing client) are V2.
What about serverid compatibility?
* over the last few months we've refactored the way clients use storage
servers, to split their notion of "serverid" (aka "peerid") into
several pieces. V2 announcements provide specific values for these
different pieces, so that some can remain the same as before, while
others are new. (this process is about 80% complete)
* "serverid" will be used to mean the Ed25519 pubkey (but some code
still uses it to mean the tubid.. this will eventually be fixed). This
is the servers's long-term secure identifier, suitable for #467-style
server designation. Old V1 nodes won't have serverids, so it won't be
possible to securely reference a V1 node, so using #467 will depend
upon upgraded servers and an upgraded Introducer.
* "name" is used to describe servers on the Welcome page, and is either
the pubkey (if available) or the tubid. It is not secure, in the sense
that it could be spoofed, and so shouldn't be used for #467-style
* "permutation seed" is used by the server-selection algorithm. It is
provided by the server (which can use anything it likes). Brand new V2
servers use the ed25519 serverid. Old V1 servers use the foolscap
tubid (i.e. when V1 tuples are upgraded by the Introducer to V2 dicts,
it adds a "permutation-seed-base32" key derived from the tubid). V2
servers which wake up with existing shares will use their tubid
forevermore, since that probably means other clients have known them
by the tubid, so they'll be expecting share placement based upon the
old tubid. This allows backwards compatibility for old shares while
allowing brand new empty servers to live in the future, not the past.
* "lease seed" is always the tubid, and continues to be used to generate
the per-share per-server lease-renew/cancel secrets. To safely use a
shared secret, you have to send that secret over a very specific
channel, which means they're tied to a transport protocol and a
verifiable endpoint. So they won't be usable in a post-Foolscap world
anyways. The plan (as part of #666) is to replace shared-secrets with
per-lease Ed25519 keypairs.
* "foolscap write enabler seed" is also the tubid, for exactly the same
reasons. We'll need to replace both lease-management and mutable-file
write-management before we can move from Foolscap to unencrypted HTTP.
* serverids currently include a short version marker: the "v0-" in
"v0-fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq". Does that
get in the way of cut-and-paste? Would it be better to use something
like "v0fcmgu663rdyshncihts4e45rtwjwvc7ebcrtlaiv345yyps667pq"? When we
abbreviate these in places like the FileChecker results page (to
identify specific servers), is there a way to get the v0- out of the
abbreviated form? (maybe use a "-v0"/"v0" suffix? maybe define the
abbreviated form to skip the prefix, so this example appears as just
* are there places where I've missed the tubid-to-serverid transition? I
spotted one just now, the "My nodeid" field on the welcome page.
* Next steps: push forward on the Accounting work, specifically looking
for ways to display (to clients) which servers you're using, and then
maybe to exert some control over that list. There are some UI
questions to figure out: I can imagine managing this config with both
tahoe.cfg (have a config key with a list of serverids) and via a web
page (a <table> with enable/disable checkboxes), but the latter
requires some web-security frameworking that we don't have in place
yet (and might not want to rely upon anyways).
Let me know if you have an questions.. I imagine some of this is as
clear as mud.
More information about the tahoe-dev