Advancing the state of Tahoe-LAFS storage server access control

[Jean-Paul Calderone]

Dear Tahoe-LAFS community,

Over the years, we’ve discussed various approaches to accounting and grid
access control. Our team is now interested in extending the Tahoe-LAFS
protocol so as to provide more granular access-control to storage server
resources. There are situations in which it might be desirable to limit
access to particular users -- for example, to deny access to abusive users,
or to require compensation to storage server operators before access is
granted -- without inconveniencing (e.g., by requiring migration to a new
set of storage fURLs) other users.

In our particular case -- supporting the PrivateStorage.io Tahoe-LAFS
deployment -- we are interested in providing paid access to Tahoe-LAFS
storage servers.  This implies the ability to revoke access to those
servers when a user chooses to end their relationship with the service. We
are interested in doing this in a way that improves Tahoe-LAFS for everyone
and generally fits with the project's overall goals. We would like to work
with you to be able to contribute this code back to the master Tahoe-LAFS
branch.

We are operating with these requirements in mind:

   -

   Preserve Tahoe's existing privacy properties: Unlinkability a) between
   individual shares, and b) between shares and the users that can read/write
   them -- in other words, minimize server-side tracking and metadata trails
   -

   Preserve Tahoe's existing use-cases (friendnets, etc.)
   -

   Create the ability to deny share read and write access per-storage
   server based to certain users.

The approach we are most actively exploring now is to expand most of the
storage server APIs that involve shares, perhaps starting with the lease
management APIs add_lease and renew_lease, but not necessarily being
limited to these. These would change to have one or more new optional
parameters giving some value that proves a right to access.

The storage server would also be extended to support pluggable
interpretation of these values, allowing policy to be set by the server
operator. One such policy, likely the policy we will pursue, is to have a
PrivacyPass-like token (https://privacypass.github.io/protocol/) which can
be issued upon receipt of payment (rather than completion of a CAPTCHA as
is PrivacyPass' original intended use). (Credit to Str4d for suggesting
this approach to Liz.) Other policies could include signed access tokens,
shared secrets, cryptocurrency systems, and other sophisticated
cryptographic protocols.

This approach is inspired and informed by many past discussions within the
community about economic models for Tahoe-LAFS usage, too many to link to.

The questions we have for the Tahoe-LAFS community are:

   -

   Would you be interested in having these changes roll into Tahoe-LAFS
   -

   Are there other approaches we should discuss in the community?
   -

   If you are a storage grid operator, would you use this? If so, how would
   you like to bill/charge users of grids (bandwidth? bytes-stored over time?
   access over time? etc.)? -- in other words, how could our implementation
   better-support your desired use-case?

Thanks!
Jean-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20190528/e81f0055/attachment.html>