[tahoe-dev] #466 state-of-the-patch

[Zooko O'Whielacronx]

(For the record, Brian and I chatted about this on IRC tonight and
discussed most or all of what I write below.)

Great work!

Overall, it looks great. I have a series of comments and suggestions
which I intend to post in a series of replies. I will have time
tonight to write about only one important detail:

On Sat, Feb 12, 2011 at 2:10 PM, Brian Warner <warner at lothar.com> wrote:
>
> But since we've been using foolscap tubids as serverids, and since we've
> been using serverids to compute both serverlist-permutation and
> shared-secrets, there is a compatibility concern. Any shares we've
> uploaded to tubid-based servers must continue to be accessible with the
> old serverid.

I like to think about this in terms of the minimal requirements on
your use of the write-enabler instead of in terms of "identities".
(Thinking in terms of "identities" often bundles together requirements
that don't need to be bundled together.)

The client, in both current v1.8 and in future v1.9, sends an
unguessable string of its own choosing as the "write-enabler" whenever
it creates a new mutable share, telling the server "Don't allow anyone
to overwrite this share unless they tell you this unguessable
password.". As a matter of fact the v1.8 client derives that
unguessable string by (basically) hashing together the write cap and
the server's tubid, but the server has no way of knowing that. Future
clients don't *have* to generate their write enablers the same way,
but if they generate them differently then clients <= v1.8.2 won't be
able to overwrite shares that those future clients have written.

>  I think this means that, even when we add an ECDSA pubkey
> to those servers, they need to continue to use their tubid as serverid,
> and we need to allow an announcement signed with pubkey-A to correctly
> claim to have a serverid tubid-B. This will require a verification step,
> in which the client connects to the tubid-B-bearing FURL, and the server
> is expected to announce (over that channel) that it uses pubkey-A. Once
> that is accomplished, the client can believe other metadata included in
> the signed announcement.

After discussion with Brian on IRC tonight, I don't think that the
above is really necessary. If we allow servers to put a FURL of their
own choosing in the signed announcement but we don't verify that the
controller of the private key determined by that FURL agrees that the
FURL ought to appear in that announcement, then this doesn't allow a
server to learn the write-enabler for any other server. That's because
the client will never send a write-enabler to a server using a FURL
unless that write-enabler was generated from the tubid in that FURL.

(I think this is an example of how "identity-oriented" thinking can
make things harder -- if the client thinks that a server has a
canonical identity, and it is going to use that identity for
generating write enablers, verifying announcements, and other things,
then the client thinks it has to do extra work to cross-verify those
two identities. But in truth doing that work is not necessary to
ensure that it never sends a write-enabler to the wrong server.)

Regards,

Zooko