On Dec 13, 2009, at 3:47 PM, Mark S. Miller wrote:
On Sun, Dec 13, 2009 at 3:19 PM, Maciej Stachowiak <[email protected]>
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
