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

Comments inline

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

The question is whether separating credentials from naming has
advantages over keeping them together. The references talk about
certain kinds of putative advantages that have been proven illusory.
It is true that there may be other advantages that haven't been
articulated or surfaced. Mark is asking for help in understanding what
they are.

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

If the security considerations can't be convincing, then you are
making your judgment of the inadequacy of the capability approach
based on other considerations. I think there is a sincere question as
to what those considerations are.

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

Because the trusted computing base can always have flaws, and desired
security policy may be formalized incorrectly, there is *always* risk.
When comparing approaches based on security criteria, you have to ask
which approach has lower risk. When applying other criteria, the
questions are different. This may be a disagreement over "goodness",
so we need to work on being transparent about what "good" means.

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

This is a straw man as it does not address the question on the table.
As far as I know, even if current credential-carrying same-origin
requests are being challenged, prohibiting them is in neither the
interest nor the power of the WG, so it's off the table. (Mark may
argue for deprecation, but that in itself will have little effect.)
AFAICT we are only talking about permitting cross-origin requests that
are currently forbidden. That is, the working group's recommendation
will only benefit new code, not restrict old code. The only
incompatibility will be with deployed resource/user-agent combinations
that conspire in a nonstandard way to get around SOP protection AND
that unilaterally choose to switch to a standard means of protection.

The relationship of UM to capabilities is that if you want to protect
against GET of a resource using UM (i.e. if it's not a completely
public resource), then you have to protect it by making one or more of
the request arguments unguessable. Unguessable information and
capabilities have similar properties, such that a vulnerability or
incompleteness in the latter would turn imply a vulnerability or
vulnerability in the former. It sounds like no one is disputing the
security or completeness of UM, and that no one is going to be
convinced that security and completeness are practical problems with
CORS.

The only complaint I know of regarding UM is that it is so complicated
to use in practice that it will not be as enabling as CORS, and would
therefore create community pressure for some new kind of SOP opt-out.
I think this is an interesting question, so it would be useful to
drill down on it.

Whether by CORS or UM, we are making the web less secure by punching a
hole in an established barrier. But I see two different kinds of
risks: one is the *impossibility* of using the mechanism to implement
desired policy, and the other is the *difficulty* of using the
mechanism to implement desired policy. Mark says: CORS = difficult or
impossible to use correctly; UM = easy to use correctly. Adam (and
others) say: CORS = easy to use with low risk (i.e. "not very
incorrectly"); UM = hard to use correctly. Since the question of
whether the CORS risk is "low enough" seems subjective and
intractable, maybe we (Mark?) should  instead attempt to assess how
hard/easy it is to use UM correctly, as compared to using CORS with
the risks it takes on. That is, even if the UM security benefit is
clear, it should still be compared against its costs.

Regarding the idea that UM is unproven or undeployed - I think this is
a peculiar charge given that object-oriented programming dates from
1967, and actors date from 1973; and current use of the capability
pattern, for example in email list validation, shared calendar access
control, and CSRF defense (Mark can probably provide many other and
better examples), *is* something we can build on. Ocaps have been
essentially unchanged for 40 years, with essentially no elaboration or
revision despite heavy stress testing. AFAIK the academic and
practical security communities have not converged on any distributed
(i.e. multilateral) access control system *other* than capabilities.

> Regards,
> Maciej

Best
Jonathan

Received on Monday, 14 December 2009 13:53:48 UTC