Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Sun, Dec 13, 2009 at 3:19 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> 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:
>
>
I am not the one who brought up the controversy dating from the '70s as
relevant to this discussion. I am merely clarifying how one should interpret
the history of that controversy.



> 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 benefits 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.
>
> Agreed. Since no one any more challenges the assertion that ocaps are
superior to ACLs in some ways, the remaining question is whether ACLs are
superior to ocaps in other ways. If they are not, then ocaps and simply
strictly superior to ACLs. The references cited refute prior claims about
weaknesses of ocaps compared to ACLs.



>
> [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.
>
> Yes, my mistake. The second link is another link to Horton, not to Myths.


> 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).
>
>
Adam is an expert. I am challenging him wrt the status of the debate in the
scientific literature and what we should conclude from it, since he raised
the topic.

>
> [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.
>
> I actually think the *-properties are almost completely unimportant, and
hardly ever relate to any practical issue. However, Boebert's impossibility
claim was then repeatedly cited, including by several influential papers
which were award winning at their conferences. This history of
misunderstanding was a crucial part of the dynamic by which academia came to
dismiss capabilities.

The present debate is about confused deputy. I am aware of no papers
responding to the ocap community's analysis of the confused deputy problem.
Adam's own "Robust defenses for cross-site request forgery" <
http://portal.acm.org/citation.cfm?id=1455782> fails to even mention that
CSRF is a manifestation of a confused deputy problem. His "robust" defense
is the Origin header, which, as we have seen, merely moves the original
problem around without solving anything.

>
> 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.
>
>
If there are undisputed weaknesses of ACLs compared to capabilities, and
undisputed refutations of all claimed weaknesses capabilities compared ACLs,
then what more is needed for the science to be settled?



> 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.
>

Fine with me. That's what we were doing before Adam raised the history of
this controversy as an argument that we should stop.


-- 
   Cheers,
   --MarkM