| | 2 | |
| | 3 | Described in http://allmydata.org/pipermail/tahoe-dev/2010-February/003910.html as follows: |
| | 4 | |
| | 5 | {{{ |
| | 6 | Dear people of tahoe-dev: |
| | 7 | |
| | 8 | I've been hosting my blog on Tahoe-LAFS since July, 2008. That's 18 |
| | 9 | months now! Amazing. There are now a lot of copies out there of the |
| | 10 | URL to my blog, which is: |
| | 11 | http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html |
| | 12 | . (The URL to my blog includes, of course, the read-cap to my blog.) |
| | 13 | |
| | 14 | I was thinking recently about what will happen we deploy New Cap |
| | 15 | Design and I want to upgrade my blog to take advantage of the new |
| | 16 | style caps. When I do so the read-cap will have to change. I would |
| | 17 | want to preserve the unforgeability property -- the guarantee that if |
| | 18 | you have the read-cap to my blog you can't be tricked into accepting a |
| | 19 | forged document that was generated without the write-cap to my blog. |
| | 20 | |
| | 21 | Of course, I could just add a new blog entry in my old blog saying "My |
| | 22 | blog has now moved to $HERE, please update your bookmarks |
| | 23 | accordingly.", with the new read-cap. This would preserve the |
| | 24 | unforgeability property, but it can take a long time for everyone in |
| | 25 | the world to update their bookmarks, and the longer it takes the |
| | 26 | longer those people would be vulnerable to forgeries (by an attacker |
| | 27 | who succeeds at cracking the RSA digital signatures that provide the |
| | 28 | unforgeabilithy of my old blog). Also, asking them to do this is a |
| | 29 | hassle, so I would not do it unless the old cap style had become |
| | 30 | *really* old and troublesome -- I would keep using the old cap for a |
| | 31 | long time just to avoid this "manually asking people to change their |
| | 32 | links". |
| | 33 | |
| | 34 | Also, this text "My blog has now moved to $HERE" is not standardized |
| | 35 | and machine-readable, so you can't write a script that will reliably |
| | 36 | detect this sort of note and update your bookmarks for you. |
| | 37 | |
| | 38 | Then I had an idea: secure HTTP 301 Moved Permanently! |
| | 39 | |
| | 40 | We could extend the Tahoe-LAFS cap format so that when you ask for the |
| | 41 | current version, there is a special symbol along with a new read-cap |
| | 42 | (out-of-band of the file contents so that there is no ambiguity about |
| | 43 | file contents versus the 301 Moved Permanently symbol). This special |
| | 44 | symbol means that the client should download the new read-cap, |
| | 45 | remember for future reference that any attempt to load the old |
| | 46 | read-cap should instead use the new read-cap, and then (if possible) |
| | 47 | fetch the contents of the file using the new readcap. |
| | 48 | |
| | 49 | Note that this dovetails very nicely with my previous proposal for |
| | 50 | write-cap revocation (#954). If you are going to issue a secure LAFS |
| | 51 | 301 Moved Permanently, then you also want to petrify that file so that |
| | 52 | nobody can later change it. |
| | 53 | |
| | 54 | Note that the part about the client "remembering for future reference" |
| | 55 | suggests the existence of a client-side database which records the |
| | 56 | fact that a specific URL has been 301'ed and optimizes out the step of |
| | 57 | looking up the old location next time. This might fit in well with the |
| | 58 | backupdb, which already likes to remember a few key facts about files |
| | 59 | and directories to optimize backups. It might also be a good idea to |
| | 60 | update parent directories which point to that file or directory with |
| | 61 | the 301 information (#956). |
| | 62 | |
| | 63 | This is a forward-compatibility issue because, as in the case of my |
| | 64 | blog, the sooner we can rely on this feature the easier we can upgrade |
| | 65 | to future versions of caps. I've created #958 to track this issue. |
| | 66 | |
| | 67 | Regards, |
| | 68 | |
| | 69 | Zooko |
| | 70 | |
| | 71 | http://allmydata.org/trac/tahoe-lafs/ticket/954# revoke write authority |
| | 72 | http://allmydata.org/trac/tahoe-lafs/ticket/955# use client-side |
| | 73 | storage to defend against rollback attack |
| | 74 | http://allmydata.org/trac/tahoe-lafs/ticket/956# embed security |
| | 75 | metadata in parent directory |
| | 76 | http://allmydata.org/trac/tahoe-lafs/ticket/957# embed security metadata in URL |
| | 77 | http://allmydata.org/trac/tahoe-lafs/ticket/958# LAFS 301 Moved Permanently |
| | 78 | }}} |
