LAFS 301 Moved Permanently

[zooko]

Make it possible to mark a cap as moved-permanently, including possibly to a cap of a newer version.

Described in ​http://allmydata.org/pipermail/tahoe-dev/2010-February/003910.html as follows:

Dear people of tahoe-dev:

I've been hosting my blog on Tahoe-LAFS since July, 2008. That's 18
months now! Amazing. There are now a lot of copies out there of the
URL to my blog, which is:
http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html
. (The URL to my blog includes, of course, the read-cap to my blog.)

I was thinking recently about what will happen we deploy New Cap
Design and I want to upgrade my blog to take advantage of the new
style caps. When I do so the read-cap will have to change. I would
want to preserve the unforgeability property -- the guarantee that if
you have the read-cap to my blog you can't be tricked into accepting a
forged document that was generated without the write-cap to my blog.

Of course, I could just add a new blog entry in my old blog saying "My
blog has now moved to $HERE, please update your bookmarks
accordingly.", with the new read-cap. This would preserve the
unforgeability property, but it can take a long time for everyone in
the world to update their bookmarks, and the longer it takes the
longer those people would be vulnerable to forgeries (by an attacker
who succeeds at cracking the RSA digital signatures that provide the
unforgeabilithy of my old blog). Also, asking them to do this is a
hassle, so I would not do it unless the old cap style had become
*really* old and troublesome -- I would keep using the old cap for a
long time just to avoid this "manually asking people to change their
links".

Also, this text "My blog has now moved to $HERE" is not standardized
and machine-readable, so you can't write a script that will reliably
detect this sort of note and update your bookmarks for you.

Then I had an idea: secure HTTP 301 Moved Permanently!

We could extend the Tahoe-LAFS cap format so that when you ask for the
current version, there is a special symbol along with a new read-cap
(out-of-band of the file contents so that there is no ambiguity about
file contents versus the 301 Moved Permanently symbol). This special
symbol means that the client should download the new read-cap,
remember for future reference that any attempt to load the old
read-cap should instead use the new read-cap, and then (if possible)
fetch the contents of the file using the new readcap.

Note that this dovetails very nicely with my previous proposal for
write-cap revocation (#954). If you are going to issue a secure LAFS
301 Moved Permanently, then you also want to petrify that file so that
nobody can later change it.

Note that the part about the client "remembering for future reference"
suggests the existence of a client-side database which records the
fact that a specific URL has been 301'ed and optimizes out the step of
looking up the old location next time. This might fit in well with the
backupdb, which already likes to remember a few key facts about files
and directories to optimize backups. It might also be a good idea to
update parent directories which point to that file or directory with
the 301 information (#956).

This is a forward-compatibility issue because, as in the case of my
blog, the sooner we can rely on this feature the easier we can upgrade
to future versions of caps. I've created #958 to track this issue.

Regards,

Zooko

http://allmydata.org/trac/tahoe-lafs/ticket/954# revoke write authority
http://allmydata.org/trac/tahoe-lafs/ticket/955# use client-side
storage to defend against rollback attack
http://allmydata.org/trac/tahoe-lafs/ticket/956# embed security
metadata in parent directory
http://allmydata.org/trac/tahoe-lafs/ticket/957# embed security metadata in URL
http://allmydata.org/trac/tahoe-lafs/ticket/958# LAFS 301 Moved Permanently