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

On Dec 13, 2009, at 3:47 PM, Mark S. Miller wrote:

> On Sun, Dec 13, 2009 at 3:19 PM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>
>
> 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?

Even if that is true with respect to formal security properties (and I  
honestly don't know), it doesn't necessarily show that ACL-based  
systems are always dangerously unsafe, or that the formal differences  
actually matter in practice in a particular case, enough to outweigh  
any pragmatic considerations in the other direction.

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

One important point to consider is that we are not deploying into a  
vacuum. The Web already pervasively makes use of tokens that are  
passively passed around to identify the agent (I feel a little weird  
calling these ACLs given the specific uses). In particular, the notion  
of origin is used already to control client-side scripting access to  
the DOM; and cookies are used pervasively for persistent login.

I don't see a clear plan on the table for removing these passive  
identifiers. Removing same-origin policy for scripting would require  
either majorly redesigning scripting APIs or would lead to massive  
security holes in existing sites. As for cookies, it does not seem  
anyone has a practical replacement that allows a user to persistently  
stay logged into a site. In fact, many proposed mechanisms for cross- 
site communication ultimately depend at some point on cookies,  
including you and Tyler's proposed UM-based protocol for cross-site  
communication without prior arrangement.

Even if a pure capability-based system is better than a pure ACL-based  
system (and I really have no way to evaluate, except to note that a  
large number of security architectures in widespread production use  
seem to be on some level ACL-based), it's not clear to me that solely  
pushing capabilities is the best way to improve the already existing  
Web.

There seem to be two schools of thought that to some extent inform the  
thinking of participants in this discussion:

1) Try to encourage capability-based mechanisms by not providing  
anything that lets you extend the use of origins and cookies.
2) Try to build on the model that already exists and that we are  
likely stuck with, and provide practical ways to mitigate its risks.

I don't see how we are going to settle the disagreement by further  
mailing list debate, because it seems to me that much of it is at the  
level of design philosophy, not provable security properties.

Regards,
Maciej