[cap-talk] "ACLs don't" paper rejected from Oakland 09
David Wagner
daw at cs.berkeley.edu
Thu Jan 29 02:04:54 EST 2009
I wouldn't feel too demoralized. I'd view these reviews as mildly
encouraging. Several of the reviewers seemed fairly receptive to the
points you are making. I'd treat these reviews as an encouragement to
revise and resubmit (probably to a conference one step down from Oakland)
-- say, to SACMAT, or HotSec, or New Security Paradigms, or maybe ACISP
or SECURECOMM. New Security Paradigms is looking for papers on new
security paradigms, right?
Perhaps it is worth mentioning that Oakland accepted only 10% of papers,
and that Oakland is probably the most selective, choosy conference in
all of computer security. As a program committee member, I saw that
Oakland rejected a number of papers that I fully expect to get published
elsewhere.
Your paper seems to me like the kind of paper that academic conferences
are likely to be reluctant to publish, or that it will be difficult for
them to publish. Review #31D explains why nicely. Yours is a paper on
broad principles, with arguments from first premises. Those papers are
much harder to publish, and I'd expect the community to be much less
receptive to them (e.g., reviewers are going to be concerned, is this
just a religious argument? is this philosophy? how do I know whether
the principles proposed here are the right ones?). Compare to a more
typical paper which proposes a new algorithm or technique or system
and evaluates it carefully, or which picks a narrow problem that no one
has solved before and solves it, or proves a new theorem; such papers
have many specific technical details whose correctness and merits are
relatively easy to evaluate. In comparison, broad principles papers are
much harder to evaluate. If you put a broad principles paper up against
a paper that proves a new, really difficult theorem, or that builds a
huge new system and evaluates it carefully, it's going to be really hard
for a principles paper to win that head-to-head match. It's very rare
for conferences to publish such principles papers. So, I'd fully expect
principles papers to get rejected a few times before being accepted.
It seems like the reviews provide some helpful information for how to
improve the paper. For instance, Review #31B clearly didn't understand
some of the key points you were trying to make; so how can the paper be
revised to make those more clearly? And Reviews #31C and #31D have other
helpful suggestions and comments that can help to refine the presentation.
My rule of thumb is that "the reviewer is always right", in the sense
that if the reviewer didn't understand something, then that's usually
an indication that a good chunk of the audience probably won't, either,
and so it makes sense to see what can be done to improve the presentation
to make the point more clearly.
It's amusing that Review #31D points to your own web page as one of
the sources for the fact that clickjacking is a confused deputy problem.
It shows that you are being effective in spreading this message. :-)
Bottom line: I don't view see any reason to be discouraged.
-- David
P.S. Full disclosure: I was a member of Oakland program committee.
However I have no inside information at all on this paper; I was marked
as a "conflict" for this paper and as a result did not see any of the
internal discussion, reviewing, etc. (Committee members step out of
the room whenever the committee discusses a paper they are conflicted
on, and the reviewing system doesn't allow us to see reviews or
discussion of papers that we're conflicted on.)
Tyler Close wrote:
>Hi all,
>
>This past fall, in the wake of the clickjacking news, I set about
>writing a paper to clearly explain to the world why ACLs, and derived
>works, cannot possibly work for access control in multi-user systems
>like the Web. I thought I did a pretty good job, and so submitted it
>to the Oakland security conference. Unfortunately, I was unable to get
>my point across to the reviewers. I thought a coherent argument
>explaining why ACLs don't actually do any of the things they are
>commonly believed to do would be an important contribution. AFAICT,
>the reviewers believe the ACL model has already fallen into complete
>disrepute, but simultaneously don't seem to quite get it. Other
>reviewers seem to have missed sections of the paper where I thought I
>clearly answered questions they seem to still have.
>
>I've put the oakland09 submission, rejection email, and my updated
>version of the paper at:
>
>http://waterken.sourceforge.net/aclsdont/
>
>I'm feeling demoralized now. Constructive criticism and productive
>next steps appreciated.
>
>--Tyler
>
>-----Original Message-----
>From: oakland09-pcchairs-l at cs.cornell.edu
>[mailto:oakland09-pcchairs-l at cs.cornell.edu]
>Sent: Wednesday, January 28, 2009 5:46 PM
>To: Close, Tyler J.
>Cc: Andrew Myers
>Subject: [Oakland09] Rejected paper #31 "ACLs don't"
>
>Dear Tyler Close,
>
>We are sorry to inform you that your submission, "ACLs don't", was not
>selected for publication by the program committee for the 2009 IEEE
>Symposium on Security and Privacy. The selection process was highly
>competitive, with only 26 of 254 submissions selected.
>
>Reviewers' comments are included below and are available at the reviewing
>website:
>
> http://oakland09.cs.cornell.edu/oakland09/paper.php?p=31
>
>We hope that these reviews will be useful to you.
>
>Thank you for submitting to IEEE Security and Privacy, and we hope to
>see you at the conference in May!
>
>Best regards,
>Andrew Myers and Dave Evans,
>Co-Chairs, 2009 IEEE Symposium on Security and Privacy Program Committee
>
>===========================================================================
> Oakland09 Review #31A
> Updated Tuesday 2 Dec 2008 4:07:57pm EST
>---------------------------------------------------------------------------
> Paper #31: ACLs don't
>---------------------------------------------------------------------------
>
> Overall merit: 3. Weak reject: will not argue against
> Reviewer confidence: 3. Confident
> Correctness: 4. Convincing
> Presentation: 4. Well written
> Relevance: 4. This is a reasonable venue for this
> paper
> Novelty: 2. Probably done before
>
> ===== Summary of paper =====
>
>This paper discusses limitations of the ACL model in multi-principal settings.
>
> ===== Recommendation =====
>
>
>This paper discusses limitations of the ACL model in multi-principal settings.
>
>Obviously it is commonly agreed that "the view presented in the
>Protection paper that ACLs and capabilities are merely different
>implementation choices for a single access model embodied by the
>access matrix is incorrect."
>
>This knowledge has been around for decades however. ACLs differ from
>capabilities in dozen ways or more. Simply countering a claim made in
>the original papers on AC might not be very relevant. It would be more
>interesting to see if the nuances discussed here have not been
>presented elsewhere also.
>
>I might be biased, but while reading the paper I was trying to
>identify items that I was not aware of before. And while indeed I am
>not aware of another effort that discusses all these issues together,
>I would assume that any serious system security course would touch on
>most of them in its AC section.
>
>Ultimately, I feel this would be probably suited better as part of a
>paper discussion a novel AC mechanism that solves some of the issues
>-- e.g., in the context of a a browser AC plugin that defends against
>CSS or similar etc.
>
>Finally, the paper has not been anonymized properly. The
>acknowledgment section should probably have been eliminated.
>
>===========================================================================
> Oakland09 Review #31B
> Updated Friday 19 Dec 2008 4:41:46am EST
>---------------------------------------------------------------------------
> Paper #31: ACLs don't
>---------------------------------------------------------------------------
>
> Overall merit: 2. Reject: will argue to reject
> Reviewer confidence: 3. Confident
> Correctness: 2. Unconvincing
> Presentation: 2. Hard to follow
> Relevance: 3. Not sure whether it belongs here or
> in another venue
> Novelty: 3. Unsurprising next step
>
> ===== Summary of paper =====
>
>This paper purports to show a limitation of ACLs: The ACL model is
>unable to make correct access decisions for interactions involving
>more than two principals, since required information is not retained
>across message sends.
>The critique is based on CSRF and clickjacking; which are web attacks
>that involve 3 parties: a dishonest site, an honest user, and an
>honest site (the victim).
>
> ===== Recommendation =====
>
>The contribution of this paper is not evident. The discussion about
>limitations of ACL and advantages of capability model is a high-level,
>almost philosophical treatment of the topic.
>What specific measures could be used to prevent CSRF? How would they
>be implemented in the browser, or at a web site? If the authors of the
>paper truly believe they have a solution to CSRF, then they should
>implement it and reap the benefits of success
>
> ===== Comments for authors =====
>
>The paper says, "Though these victim applications may correctly
>implement traditional access control lists (ACLs), somehow the
>attacker still gains access to resources that are supposed to be
>inaccessible" However it is not clear where the ACL lies in this
>analysis. Is the browser security policy considered as an ACL? Is the
>ACL something at the victim site?
>
>In analysis of CSFR, the paper says, "Although the CSRF article makes
>no reference to the Confused Deputy attack or capabilities, the
>suggested defense is effectively to transition the application away
>from the ACL model and to the capability model". It is not clear this
>this reviwer what the paper is talking about. The three main defenses
>against CSRF are (i) unguessable tokes in forms, (ii) checking the
>referrer header, and (iii) custom headers, as implemented with
>XmlHttpRequest (XHR). What does the capability model have to do with
>these standard defensesw?
>
>The author(s) similarly does not seem to be aware of the current
>defense against simple clickfraud that uses randomized links. These
>are arguably meant to be capability like, but still defeated by
>clickjacking attacks.
>
>The discussion of web phenomena seems simplistic and uninformed about
>topics that are readily available on the web.
>
>===========================================================================
> Oakland09 Review #31C
> Updated Wednesday 14 Jan 2009 6:24:44pm EST
>---------------------------------------------------------------------------
> Paper #31: ACLs don't
>---------------------------------------------------------------------------
>
> Overall merit: 3. Weak reject: will not argue against
> Reviewer confidence: 3. Confident
> Correctness: 4. Convincing
> Presentation: 5. Lucid and eloquent
> Relevance: 5. This is the natural home for this
> paper
> Novelty: 3. Unsurprising next step
>
> ===== Summary of paper =====
>
>The paper gives a well written overview of how ACLs work, pointing out
>subtle and important difference with respect to the capability
>mechanism.
>It shows that recent attacks such as Cross-Site Request Forgery and
>clickjacking are instances of the Confused Deputy attack. It suggests
>also how to solve this problem using the capability model rather than
>ACLs.
>
> ===== Recommendation =====
>
>The paper is very well written and it can be actually used as a good
>class paper to explain the differences between ACLs and capabilities.
>Many of the reported observation already appear here and there sparse
>in the security literature, however this paper has the merit to write
>all of them consistently in a single note. This is also a paper that
>explains in depth the Confused Deputy problem.
>
> ===== Comments for authors =====
>
>It is true the Protection paper didn't discuss on the fundamental
>differences between ACL and capabilities. However, many subsequent
>papers, many of which on this symposium (e.g. IBAC, KeykoS, OASIS,
>etc.), discuss extensively on the difference, in particular when it's
>matter of delegation.
>I am also surprised that delegation was barely mentioned in the paper
>since most of the problems outlined seem to boil down to: 1) hidden
>delegation while it should be made explicit to make evident when the
>Compiler act on behalf of a User (which user and on which file). 2)
>Use of ACLs instead of capabilities to implement this delegation.
>
>===========================================================================
> Oakland09 Review #31D
> Updated Tuesday 13 Jan 2009 2:06:40am EST
>---------------------------------------------------------------------------
> Paper #31: ACLs don't
>---------------------------------------------------------------------------
>
> Overall merit: 2. Reject: will argue to reject
> Reviewer confidence: 3. Confident
> Correctness: 3. Plausible
> Presentation: 4. Well written
> Relevance: 3. Not sure whether it belongs here or
> in another venue
> Novelty: 2. Probably done before
>
> ===== Summary of paper =====
>
>This paper argues that ACL-based protection systems are inferior to
>capability-based ones in the case of multi-principal interactions,
>since these interactions are prone to confused deputy attacks. The
>paper develops this idea using the "tried and true"
>users/compiler/vendor example often mentioned in the literature, but
>also shows how the points apply to Web scenarios. The paper spends
>time explaining the limitations of ACLs, some time describing how
>capabilities are better in some scenarios, and some time describing
>CSRF and clickjacking attacks in this vein. The paper is rhetoric, in
>that no new system, algorithm, or mechanism is introduced, and there
>is no evaluation.
>
> ===== Recommendation =====
>
>The paper didn't feel like it had enough "raw meat" -- many of the
>capability vs. ACL arguments mentioned in this paper have been the
>topic of religious wars in historical systems over the past three
>decades, and confused deputy attacks have been understood for some
>time (as has the fact that CSRF and clickjacking are instances of the
>confused deputy problem).
>
>I didn't entirely agree with the conclusion that capabilities solve
>the problems, or that ACLs cannot solve the problem; the paper doesn't
>really attempt to constructively find a solution to the problem using
>ACLs.
>
>The paper doesn't discuss alternative protection models that attempt
>to solve exactly these kinds of problems (e.g., information flow
>control -- see, for example, some of the recent work in the OS
>community on this topic, such as Flume or HiStar).
>
> ===== Comments for authors =====
>
>I do appreciate this style of paper -- namely one that uses rhetoric
>and thought experiments to make a new insight about system structure,
>design, or architecture. However, I think the burden on this kind of
>paper is to make a substantial leap, or resolve a long-unresolved
>problem, otherwise the paper might be inconsequential or prone to
>retreading old argument. This paper didn't really feel like it met
>the burden of a sufficiently new or substantial contribution.
>
>ACLs vs. capabilities have been long debated in many systems. The
>confused deputy article referenced in this paper ([8]) essentially
>makes the same pro-capability argument as the paper itself:
>capabilities bundle together the designation of the object that the
>deputy should operate on with the permission to access that object.
>Thus, the major premise of this paper (capabilities are better than
>ACLs) is not a new observation.
>
>CSRF and clickjacking have been recognized for several years now as
>examples of the confused deputy problem. (See, for example:
>
> http://ieeexplore.ieee.org/xpls/abs_all.jsp?isnumber=4446683&arnumber=4446703
> http://www.cgisecurity.com/csrf-faq.html
> http://waterken.sourceforge.net/clickjacking/
>
>It's true that ACLs don't bundle object designation with permission,
>but the specific compiler/user/vendor problem can be solved with
>argument validation -- the compiler verifies that the output file is a
>file that the user invoking the compiler is allowed to access before
>writing to it.
>
>Solutions other than capabilities would work, such as an
>information-flow based solution. (I agree this is harder to apply to
>the web.)
>
>The acknowledgements section is not appropriate for an anonymized
>submission -- it leaks too much information about who may have
>authored the paper. (It's fine for a camera ready, of course.)
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk
More information about the cap-talk
mailing list