I enter this subthread with trepidation, because I do not think the
Working Group is in a position to engage in a literature review on an
active research topic. However, a few comments below:
On Dec 13, 2009, at 1:29 PM, Mark S. Miller wrote:
> On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth <w3c@adambarth.com>
> wrote:
> On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller <erights@google.com>
> wrote:
> > On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth <w3c@adambarth.com>
> wrote:
> >> I agree with Jonas. It seems unlikely we'll be able to
> >> design-by-commitee around a difference in security philosophy
> dating
> >> back to the 70s.
> >
> > Hi Adam, the whole point of arguing is to settle controversies.
> That is how
> > human knowledge advances. If after 40 years the ACL side has no
> defenses
> > left for its position, ACL advocates should have the good grace to
> concede
> > rather than cite the length of the argument as a reason not to
> resolve the
> > argument.
>
> I seriously doubt we're going to advance the state of human knowledge
> by debating this topic on this mailing list. The scientific community
> is better equipped for that than the standards community.
>
>
> AFAICT, the last words on this debate in the scientific literature
> are the Horton paper <http://www.usenix.org/event/hotsec07/tech/full_papers/miller/miller.pdf
> > and the prior refutations it cites:
>
> Because ocaps operate on an anonymous “bearer right” basis, they
> seem to make reactive control impossible. Indeed, although many
> historical criticisms of ocaps have since been refuted [11, 16, 10,
> 17], a remaining unrefuted criticism is that they cannot record who
> to blame for which action [6]. This lack has led some to forego the
> beneﬁts of ocaps.
>
> The point of the Horton paper itself is to refute that last criticism.
That paper seems to respond to a criticism of object-capability
systems. Specifically, it shows a protocol that apparently lets you
associate communication with an identity in an object capability
system to allow logging and reactively restricting access. At least
I'm pretty sure it does, it took me several readings to properly
undertand it.
This paper does not appear to give an argument that capability models
are in general superior to other models.
>
> [11] Capability Myths Demolished <http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
> > or <http://www.usenix.org/events/hotsec07/tech/full_papers/miller/miller_html/
> >
Those two don't seem to link to the same paper.
> Referee rejection of Myths at <http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html
> >. Read carefully, especially Boebert's criticisms.
I'm not sure what we are supposed to conclude from the rejection
comments (or from a rejected paper in general).
> [16] Verifying the EROS Confinement Mechanism <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6577
> >
The point being made her seems too technical to relate to the current
discussion (at least to my non-expert understanding).
>
> [10] Robust Composition <http://erights.org/talks/thesis/>. Notice
> in particular the counter-example to Boebert's famous claim in seven
> lines of simple code, in Figure 11.2.
>
> [17] Patterns of Safe Collaboration <http://www.evoluware.eu/fsp_thesis.pdf
> >, which does a formal analysis of (among other things) confused
> deputy, Boebert's claim, and my counter-example.
>
> [6] Traditional capability-based systems: An analysis of their
> ability to meet the trusted computer security evaluation criteria. <http://www.webstart.com/jed/papers/P-1935/
> >
There seems to be a whole lot of material on whether capability-based
systems can enforce the *-property. It's not obvious to me how this is
relevant to the discussion. If my understanding of the *-property is
correct, it's not a property that we are trying to enforce in the
context of Web security. But to be fair, I did not know what the *-
property was until just a few minutes ago, so my opinion cannot be
considered very well informed.
>
> If you know of any responses to these refutations in the scientific
> literature, please cite them. If you believe (as I do) that the lack
> of responses is due to ignorance and avoidance, then either
> 1) the scientific community has shown itself less well equipped to
> engage in this debate than those who are actively engaged in it --
> such as us here on this list,
> 2) that the case against these alleged refutations are so obvious
> that they need not be stated, or
> 3) that the members of the scientific community that cares about
> these issues have found no flaw in these refutations -- in which
> case they legitimately should stand as the last word.
The literature you cited seems to mostly be about whether capability
systems have various technical flaws, and whether they can be made to
do various things that ACL-based systems can do. This does not seem to
me to show that the science is settled on how to design security
systems.
I'm also not sure that this Working Group is an appropriate venue to
determine the answer to that question in a general way. I don't think
most of us have the skillset to review the literature. Beyond that,
our goal in the Working Group is to do practical security analysis of
concrete protocols, and if there are flaws, to address them. If there
are theoretical results that have direct bearing on Working Group
deliverables, then the best way to provide that information would be
to explain how they apply in that specific context.
Regards,
Maciej