[tahoe-dev] StorageSS 2008 notification

[zooko]

Folks:

I wrote a paper about Tahoe for the 4th International Workshop on  
Storage Security and Survivability [1].   The current version of the  
paper is [2], the source code of the paper is [3], and the  
bibliography is [4].

Appended are the comments from the reviewers, which are all very  
useful constructive criticism.  The paper was accepted, and the final  
version is due August 3.  I hope to have improved the paper  
substantially by then.

Regards,

Zooko

[1] http://www.storagess.org/2008/
[2] https://zooko.com/lafs.pdf
[3] https://zooko.com/lafs.tex
[4] https://zooko.com/sigproc.bib

Begin forwarded message:

> From: StorageSS 2008 <storagess2008 at easychair.org>
> Date: July 3, 2008 16:58:32 PM MDT
> To: "Zooko Wilcox-O'Hearn" <zooko at zooko.com>
> Subject: StorageSS 2008 notification
>
> On behalf of the ACM StorageSS 2008 Program Committee, we are  
> delighted to inform you that your paper has been accepted to appear  
> at the conference. As soon as possible, please reply back to this  
> email to confirm you have received this notification.
>
> The Program Committee worked very hard to thoroughly review all the  
> submitted papers.  Please repay their efforts, by following their  
> suggestions when you revise your paper.
>
> You will get additional information about uploading your final  
> manuscript in a further mail. Your paper will be published in the  
> ACM Digital Library in ACM paper format.
>
> The reviews and comments are attached below.  Again, try to follow  
> their advice when you revise your paper.
>
> Congratulations on your fine work.  If you have any additional  
> questions, please feel free to get in touch with us.
>
> Best Regards,
> Yongdae Kim and Bill Yurcik, Program Chairs
> ACM StorageSS 2008
>
>
>
> ---------------------------------------------
>
> Paper: 12
> Title: Tahoe -- The Least-Authority Filesystem
>
>
> -------------------- review 1 --------------------
>
> PAPER: 12
> TITLE: Tahoe -- The Least-Authority Filesystem
>
>
> This submission describes the file systems underlying  
> allmydata.com's backup service.  It is a filesystem that relies on a
> combination of encryption, public-key derived capabilities, Merkle- 
> tree based verification data structures.  These are
> the accepted best practices for the design of file systems on  
> untrusted storage.  So, not many new or exciting concepts
> in the paper.  In the author's defense, few file systems actually  
> implement all of these.  This set of primitives are dressed
> up with some design principles of Least Authority and Reliance  
> analysis, to the good.  In addition, the file system is
> entirely open-source and it is meritorious to have technical papers  
> accompanying open-source code.
>
> It's neat to see a paper written about a commercial and open-source  
> system.  It seems like good design principles were
> employed and the users of Tahoe would be interested in this  
> publication.  It would also likely add to the user base.
>
> This reviewer's big question with this paper is "where is the  
> evaluation?"  Given that the system is real, runs, and is open
> source.  Why not perform some measurements and analysis.  Where are  
> the overheads?  What features cost the most?
> What are the performability versus security tradeoffs?  These are  
> all important questions and can only be answered
> through evaluation.  For a conference, this failing would result in  
> a reject with the recommendation to "cook it some
> more".  Maybe this can be overlooked (if it can be addressed to  
> some extent in the final version) for a short workshop
> paper.
>
>
> -------------------- review 2 --------------------
>
> PAPER: 12
> TITLE: Tahoe -- The Least-Authority Filesystem
>
>
> This paper is good for a workshop. It outlines some interesting  
> crypto problems
> and describes an open source implementation of an online backup  
> service. If this
> were a longer paper, I'd expect much more significant and careful  
> coverage of
> related work. I've included some pointers below. The writing could  
> also be
> improved. I weakly recommend that this paper is accepted.
>
> Please provide a URL/pointer to the Open Source distribution of the  
> software you
> describe. (I think it is the following: http://allmydata.org/trac/ 
> tahoe/browser,
> but please make this clear.)
>
> You mention that Tahoe tolerates "when some of them [servers] are
> malicious". You don't cite any Byzantine fault tolerant systems  
> though. I expect
> you only tolerate integrity faults on servers. More discussion of  
> how you
> tolerate Byzantine failures and discussion of related techniques  
> are necessary
> to convince me otherwise. I suggest you just reduce your claim to  
> tolerating
> integrity faults on servers (i.e., a server cannot undetectably modify
> data). Specifically, the claim that any k=3 of N=10 servers are  
> sufficient
> strikes me as potentially wrong. (The protocols for reading/writing  
> data are not
> described in sufficient detail for me to make a clearer case for my  
> concerns.)
>
> I dislike the use of footnotes on the first page. Footnote 1 should  
> be in the
> body. Footnote 2 can also be in the body as a paranthetical.  
> Footnote 3 maybe
> should remain a footnote, but I'd prefer it in the body.
>
> You don't need the outline paragraph at the end of the  
> introduction. If you do
> include it, please remove the quote marks around Related Work,  
> Future Work, and
> Conclusions.
>
> There is no discussion of key revocation and having to rekey  
> everything. I think
> one or two paragraphs on this topic would improve the paper.
>
> Please support the claims you make in the last paragraph of section  
> 4.3 "For
> immutable...". The less than 1% number is the one I am particularly  
> interested
> in. Have you traced workloads that lead you to this conclusion? Is the
> conclusion drawn from other papers?
>
> Please heavily revise section 4.4. This is by far the most  
> interesting section
> of your paper. Please clarify the specific mechanisms you are  
> currently using
> and the specific properties you want from each mechanism. You  
> introduce >10
> terms in section 4.4 and it is currently *hard* to keep them all  
> straight. My
> understanding of your mechanisms is the following:
>
> RSA public key == verification key (VK)
> RSA private key == signing key (SK)
> write key (WK) == H(SK)
> read key (RK) == H(WK)
> encryption key (EK) == H(RK, salt)
> verify capability (VC) == H(VK)
> read capabability == VC, RK
> write capability == VC, WK
>
> I suggest you try and summarize the various mechanisms I like I did  
> above. (I
> doubt my summary is correct though!)
>
> In section 4.4., please fix "encryption key with H(read_key)" with  
> "encryption
> key with H(read_{key})", and "this step is to prevent" with "This step
> prevents", and remove the parentheses.
>
> In section 4.4 you mention a "sequence number". How do you deal  
> with sequence
> numbers wrapping (overflow). Note that malicious components can  
> likely advance
> the sequence numbers arbitrarily and so this is a real concern.  
> (Google for "non
> skipping timestamps" to find the work by Bazzi on such mechanisms  
> in Byzantine
> systems.)
>
> Are 16 bytes enough for security? Maybe cite some of the folks who  
> are concerend
> about the strength of crypto, or clearly point out that there are  
> risks with any
> and all crypto. E.g., "An Analysis of Compare-by-hash", Val Henson,  
> Sun
> Microsystems, HotOS 2003.
>
> Some of the cites have weird formatting:
> - [15] is all caps
> - [16] "FEC" instead of "fec".
>
> If you want to better understand Byzantine storage than look at  
> some recent
> publications from Lorenzo Alvisi, Greg Ganger & Mike Reiter (some  
> of this work
> is about Byzantine erasure-coded stroage), and Mazieres.
>
> For archival storage you may also want to look at some of the  
> OceanStore work,
> the Venti project (FAST 2002), the MAID (massive array of idle  
> disks) project
> and follow on work, "Pergamum" and other projects at UCSC, Mary  
> Baker's work on
> digital preservation.
>
>
> -------------------- review 3 --------------------
>
> PAPER: 12
> TITLE: Tahoe -- The Least-Authority Filesystem
>
>
> The paper describes an implementation of an open-source least- 
> authority file system being commercially used.  The authors  
> describe their implementation and some practical problems they  
> faced. Unfortunately, the paper lacks novelty, evaluation, and  
> excitement - there is no single figure or table, which makes the  
> reading boring.  For an implementation paper evaluation is an  
> important part especially given that encryption and security  
> protocols add significant overheads.
>
> Small comments:
> "for for smaller keys" - duplicate word;
> citation 15: do not capitalize all words
>