[tahoe-lafs-trac-stream] [tahoe-lafs] #958: LAFS 301 Moved Permanently
tahoe-lafs
trac at tahoe-lafs.org
Tue Jan 22 14:22:45 UTC 2013
#958: LAFS 301 Moved Permanently
-------------------------+-------------------------------------------------
Reporter: zooko | Owner:
Type: | Status: new
enhancement | Milestone: soon
Priority: major | Version: 1.6.0
Component: code- | Keywords: forward-compatibility backward-
mutable | compatibility integrity newcaps newurls http
Resolution: | sftp ftpd smb availability security revocation
Launchpad Bug: | rollback research
-------------------------+-------------------------------------------------
Changes (by zooko):
* keywords:
forward-compatibility backward-compatibility integrity newcaps newurls
http sftp ftpd smb availability security revocation rollback
=>
forward-compatibility backward-compatibility integrity newcaps newurls
http sftp ftpd smb availability security revocation rollback research
Old description:
> 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
> }}}
New description:
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
}}}
--
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/958#comment:18>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list