[tahoe-dev] revocation of read-access to an immutable file Re: question about sharing...

[Zooko O'Whielacronx]

toby cabot <toby at caboteria.org> wrote the lines prepended with ">> ".

On Sat, Jun 4, 2011 at 7:59 AM, Greg Troxel <gdt at ir.bbn.com> wrote:
>
>> Sure, but let's say I realize what I've done before they've copied it.
>> From what I've heard, with the traditional FS I can close the barn
>> door and know that it's closed.  With Tahoe-LAFS I can only ask for
>> the barn door to be closed at some point in the future.

I think this is mostly a difference of distributed systems vs.
centralized systems instead of a difference of caps vs. ACLs or of
Tahoe-LAFS vs. ZFS.

In a distributed system, it can be really enlightening to think of
ciphertext as something that you cannot control the distribution of.

This is because in a distributed system--unless you have DRM--the only
way to control the distribution of something is to encrypt it and
control the distribution of the key, right? So how could you limit who
has access to ciphertext? I guess the only other option is just never
export the data--whether encrypted or not--off of your own local
system, which means it isn't a distributed system.

So, in designing Tahoe-LAFS, we embraced this assumption that you
cannot control who has copies of ciphertext. We made it so that having
the ciphertext gives you very little. You learn the length of the
share in bytes (give or take a few). If a user uploads the ciphertext
to you or downloads the ciphertext from you then you learn that they
have done so. We decided to go ahead and throw in the verification
metadata so that you can confirm whether the share has been corrupted
or not. Other than that, gaining a copy of the ciphertext by itself
doesn't give you any power.

Since someone gaining the ciphertext gives them very little power,
this increases the range of servers that you can use. It means you can
safely use servers even if they are at risk of being taken over by
attackers, for example.

Now, given these basics (which, again, I think are kind of fundamental
to any DRM-free distributed system), then how could one implement
revocation of read-access to an immutable file? First of all, how
would one implement read-access to an immutable file in the first
place? Well, there's basically only one way to do it: the only way to
give someone read-access to an immutable file is to give them the
decryption key for that file.

And revocation of read-access to an immutable file--how could one
implement that? Well, we can't un-give the decryption key, so the only
remaining option is to try to deny them the ciphertext. We could, for
example, contact the storage servers that we earlier uploaded the
ciphertext to and ask them to please delete it. This is not a complete
stinker of a design. We need, after all, to be able to delete
ciphertext in order to free up space. And people strongly feel a
desire to be able to do this sort of revocation--we should not
disregard their desires.

But there are at least two major problems with it:

1. We can't know that the servers will really delete the ciphertext
when we ask them to (what if one of them happens to be off-line at
that moment?), we can't know if someone else didn't already get a copy
of the ciphertext from the server, and we can't know if the person
from whom we wish to revoke access didn't already get a copy of the
ciphertext from the server. Imagine, for example, that I run a script
which instantly downloads and stores a copy of a file as soon as I
receive the decryption key for that file. Then you will never be able
to shut the barn door before the horse has escaped unless you change
your mind and revoke the access faster than my script runs.

2. If the servers *did* all successfully delete the ciphertext when we
ask them to, then this would deny read-access to everyone, not just to
one person. If we wanted to be able to revoke one person's read-access
without revoking everyone's, then we would have to do some more
complicated and/or inefficient process. For example, we could upload
one copy of the ciphertext, encrypted under a different key, for each
different user.

These sorts of problems are probably not insurmountable, but they do
seem to be significant issues, and after all even if we could overcome
them then the "revoke read-access to this immutable file" command
would still be unreliable (it would depend on whether our request to
delete the ciphertext managed to reach all the computers which had a
copy of the ciphertext, and whether every computer honored it, before
the target user or some other computer loyal to him got a copy).

Also, this would in a sense increase your vulnerability to the
servers! If you think you might want to use the "revoke read-access to
an immutable file" feature in the future, then you can no longer be
quite so free about which servers you employ to store your ciphertext.
Maybe you can't afford to use servers which are at risk of being taken
over by attackers, because if those servers *have* been taken over,
they might pretend to honor your revocation while secretly selling the
ciphertext to the target user.

So adding this feature would detract from Tahoe-LAFS's current virtue
of imposing very little constraint on which servers you choose to use
with it.


> That's true for immutable files.  For a directory, you can unlink the
> contents and push out a new version.  But I don't think there's been any
> analysis of how effective this is.

Ah, so revoking access to *mutable* things is a complete different ballgame. :-)

Yes, there has been some analysis of it, but I don't have time to
write any more on the subject tonight. :-) See #954.

Regards,

Zooko

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/954# revoke write authority