Advancing the state of Tahoe-LAFS storage server access control

Thu May 30 16:28:12 UTC 2019

I was cruising the issue tracker for related ideas and I found
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2084.  At first I thought to
leave some comments there tying that issue into this bigger picture but the
bigger picture somewhat overwhelms the specific use-case described in that
ticket.  So I'm going to put the comment here, instead.

I think there is a lot hiding behind this seemingly simple feature.

Perhaps foremost, currently, a commercial grid operator effectively has no
way to refuse service to any user under any circumstances.  A user who has
learned a storage server fURL can use that storage server in any way the
storage server supports: create new immutable shares and mutable slots,
read existing immutable shares and mutable slots, and add or renew leases
on existing immutable shares and mutable slots.  A commercial grid operator
may want to deny more of these than just reading existing shares and slots.

The only technical measure currently available is for server operators to
rotate their introducer and/or storage server fURLs and distribute the new
capabilities to all *other* users.  For any non-trivial grid I suspect this
is not feasible, even if we were to build automation supporting it into
Tahoe-LAFS itself (introducer fURLs are currently distributed to users "out
of band").

To overcome this, there must be some way of denying some access to some
users when some condition arises.

One solution is "accounting" along the lines of the traditional (at least
in computing) definition of that word: every user has credentials by which
they identify themselves to the grid and then an authorization decision can
be made.  For example, the identity may be checked against a payments
database to determine if it is associated with a paid-up account.  There
are many tickets (
https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~accounting&order=priority)
in this issue tracker that discuss the nuances of this approach.  In this
system, read (and all other operations) are denied on the basis of the
identity not being associated with a paid-up account and the use-case is
achieved.

This has the downside of requiring an identity system and reduces some of
the current privacy properties of Tahoe-LAFS (every share can now be
associated with an identity, shares can be linked to each other,
connections can be made between identities based on common shares
interacted with).

It has upsides, too.  They mostly follow directly from the downsides.  For
example, linking shares to an identity enables you to measure per-user
usage, impose quotas, and to immediately wipe all data belonging to a
particular user.

A different solution is "micropayments" where operations are authorized by
the presentation of a value-carrying token.  An operation is allowed if a
valid token (of sufficient value) is presented and denied otherwise.  For
example, a Zatoshi might be sent along with each operation (technical
details of how you send a Zatoshi are deliberately ignored here).  Read
(and all other operations) are denied if insufficient value is sent in the
request and the use-case is achieved.

This *potentially* has the upside of preserving the privacy properties that
"accounting" removes (if you have a privacy-preserving cryptocurrency).  It
has the downside that Blockchain-based cryptocurrencies have a transaction
settlement period that is much longer than the desired execution time of
most Tahoe-LAFS operations (reads and writes want to complete on the order
of milliseconds if not better; Bitcoin settlement period averages 10 - 60
minutes, perhaps a million times longer; Zcash is faster but not *that*
much faster) and transaction fees are also much higher than the likely
value of these transactions.  Lightning / Bolt might help eventually but
these are still fairly young systems and come with an additional layer of
complexity on top of merely using a Blockchain-based cryptocurrency.

One step *towards* Blockchain-based cryptocurrencies for micropayments is
to use an earlier, simpler form of cryptocurrency - eg, something derived
from Chaum's DigiCash.  It turns out that PrivacyPass (
https://privacypass.github.io/) has much in common with DigiCash while
updating a number of the cryptographic primitives to more recent
constructions with nicer properties than the original.  With such a system,
clients would send along one or more tokens with each request and the
request would be satisfied if the value of the tokens covered the cost of
the operation.

The upside of such a DigiCash/PrivacyPass-based system is that the
settlement period is basically as fast as you can make it (verify a
signature) while all of the current privacy properties of Tahoe-LAFS are
kept intact.  The downside is that such systems rely on a "central bank" to
issue tokens (and consequently the tokens are only of value to parties with
a relationship to that central bank; the tokens are a kind of "company
scrip").  This may not prove to be much of a downside for a Tahoe-LAFS
commercial grid operator - who can act as that central bank for a token
that carries value on their own grid (with which they have an obvious
relationship).  And much of the groundwork to support this system would
also be necessary to support Blockchain-based cryptocurrency micropayments
systems or other cryptocurrency systems (perhaps a friendnet cryptocurrency
where every storage server operator mints and distributes their own coins;
meejah pointed out this was discussed as "storage clubs" at the 2016
summit, see
https://tahoe-lafs.org/pipermail/tahoe-dev/2016-October/009805.html).

In any micropayments system, the grid operator can make policy choices that
fit their particular business.  They can charge for any or all of read,
write, and lease extension operations.  For example, they may choose to
make reads and writes free but lease extensions cost tokens.  This provides
a rough approximation of a traditional subscription model - a user can
purchase enough tokens to extend the lease on all their files one month and
then enjoy a month of usage.  If they wish to continue the subscription,
they just repeat this process.

Or to more directly achieve the particular use-case in the ticket
description, they may choose to make reads and writes cost tokens.  In this
case, once a user uses all of their existing tokens and chooses not to buy
more, they are unable to read their data (but, perhaps usefully or
interestingly, any users they have shared those shares with who continues
to buy tokens can continue to use them).  This is precisely the described
use-case.  Along with the right lease policy (perhaps leases are checked
once a year for garbage collection) this can give some balance between data
retention for returning customers and the need to clean up
unused/unwanted/unpaid-for shares.

Jean-Paul

On Tue, May 28, 2019 at 8:36 AM Jean-Paul Calderone <
jean-paul+tahoe-dev at leastauthority.com> wrote:

> 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/20190530/39f0718e/attachment.html>