[tahoe-dev] what do we want from decentralized introduction?

[Jeffrey Schiller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Let me take a stab at this (I'm just new to this party, but not to
security :-) ).

A set of servers (and clients) participating in a Tahoe Grid represent
a set of trusted entities. The key to this kingdom is the furl of the
introducer. Using this furl, storage nodes and client nodes (yeah, I
know that storage nodes are just client nodes offering the storage
service, but that is a detail) register their contact furls (via the
introducer) with each other. Once you are in the party you are trusted
to behave properly. For example I can operate a storage node that
intentionally corrupts any shares that it receives. The beauty of the
Tahoe architecture is that this will not destroy data unless I can
register enough storage nodes such that I control the majority of
nodes that shares go to. Put another way, if I can corrupt enough
shares of your file that there are not a quorum of good shares
elsewhere, then I have you.

So an interesting attack on Tahoe-LAFS is to register a whole bunch of
bad behaving storage nodes. If I have the introducer furl, I can do
it.

[If someone with deeper knowledge knows a defense that I didn't find
in the code, please correct me, I won't mind :-) ].

Adding a distributed introducer doesn't materially change this
situation. To attack a grid, I would only need one of them (after I
join I will learn the others, but that doesn't really matter). So
instead of 1 root secret, there now is a set of secrets.

An important feature of Tahoe (as provided by the foolscap library) is
that if I do not have a full furl (including all the base32 "stuff"),
I cannot successfully make use of a service. So my private grid is
safe from outside interlopers (as safe as any code can be that is
internet facing, though I can firewall my grid nodes if I am more
paranoid).

A future enhancement that would add some protection would be to have
two access points (different furls) for the introducer. One would
permit clients to register as a storage server and another that would
not. I haven't done enough analysis to determine if the storage
servers themselves would require two access points as well.

Tahoe-LAFS also offers no protection against bad behaving clients
consuming too many resources. This would require some per-client
accounting and allocation limits. Similarly I can envision a system
where there is a separate "authentication/authorization" service that
would permit grid admins to create something like an account (or
capability) that a client would need to have before it could join the
grid.

Whether any of this additional work makes sense depends on the use
case that Tahoe-LAFS will evolve to address. It is probably fine the
way it is for private grids and even semi-public grids where the nodes
are run by cooperative parties.

It is also possible to have a private grid serve the public where the
public may only use a web interface on some set of clients. The access
control and authentication features could then be encapsulated in the
web interface. Again it all depends on what you want to use it for.

Sorry for the rambling...

              -Jeff


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFMO8d08CBzV/QUlSsRAprqAKCiWGcckVnPVzJsOAmjNTQ0NcwAwgCeJbdg
9x0RZSfJ5MJMvh0at7Ox0e0=
=oDyZ
-----END PGP SIGNATURE-----