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

On Thu, Dec 17, 2009 at 10:08 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Dec 17, 2009, at 9:15 AM, Kenton Varda wrote:
>
>
>
> On Thu, Dec 17, 2009 at 2:21 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>>
>> I'm not saying that Alice should be restricted in who she shares the feed
>> with. Just that Bob's site should not be able to automatically grant
>> Charlie's site access to the feed without Alice explicitly granting that
>> permission. Many sites that use workarounds (e.g. server-to-server
>> communication combined with client-side form posts and redirects) to share
>> their data today would like grants to be to another site, not to another
>> site plus any third party site that the second site chooses to share with.
>>
>
> OK, I'm sure that this has been said before, because it is critical to the
> capability argument:
>
> If Bob can access the data, and Bob can talk to Charlie *in any way at
> all*, then it *is not possible* to prevent Bob from granting access to
> Charlie, because Bob can always just serve as a proxy for Charlie's
> requests.
>
>
> Indeed, you can always act as a proxy and directly share the data rather
> than sharing the token. However, this is not the same as the ability to
> share the token anonymously. Here are a few important differences:
>
> - As Ian mentioned, in the case of some kinds of resources, one of the
> service provider's goals may be to prevent abuse of their bandwidth.
>

It seems more useful to attribute resource usage to the user rather than to
the sites the user uses to access those resources.  In my example, I might
want to limit Alice to, say, 1GB data transfer per month, but I don't see
why I would care if that transfer happened through Bob's site vs. Charlie's
site.


> - Service providers often like to know for the sake of record-keeping who
> is using their data, even if they have no interest in restricting it. Often,
> just creating an incentive to identify yourself and ask for separate
> authorization is enough, even if proxy workarounds are possible. The reason
> given below states such an incentive.
>

I think this is separate from the security question.  As I said earlier,
origins can voluntarily identify themselves for this purpose, just as
browsers voluntarily identify themselves.


> - Proxying to subvert CORS would only work while the user is logged into
> both the service provider and the actually authorized service consumer who
> is acting as a proxy, and only in the user's browser. This limits the window
> in which to get data. Meanwhile, a capability token sent anonymously could
> be used at any time, even when the user is not logged in. The ability to get
> snapshots of the user's data may not be seen to be as great a risk as
> ongoing on-demand access.
>

Yes, I directly addressed exactly that point...


> I will also add that users may want to revoke capabilities they grant. This
> is likely to be presented to the user as a whitelist of sites to which they
> granted access, whether the actual mechanism is modifying Origin checks, or
> mapping the site to a capability token and disabling it.
>

Sure.  This is easy to do via caps.


> How would the service provider generate a new URL for each visit to Bob's
> site? How would the service provider even know whether it's Bob asking for
> an update, or whether the user is logged in? If the communication is via UM,
> the service provider has no way to know. If it's via a hidden form post,
> then you are just using forms to fake the effect of CORS. Note also that
> such elaborations increase complexity of the protocol.
>

Assuming some UI exists for granting capabilities, as I suggested earlier,
it can automatically take care of generating a new capability for every
connection/visit and revoking it when appropriate.


> To enable permissions to be revoked in a granular way, you must vend
> different capability tokens per site. Given that, it seems only sensible to
> check that the token is actually being used by the party to which it was
> granted.
>

I disagree.  Delegation is useful, and prohibiting it has a cost.  If we
granted the capability to Bob, why should we care if Bob chooses to delegate
to Charlie?  If Charlie misuses the capability, then we blame Bob for that
misuse.  It's Bob's responsibility to take appropriate measures to prevent
this.  If we don't trust Bob we shouldn't have granted him the capability in
the first place.

And again, CORS doesn't prevent delegation anyway; it only makes it less
convenient.


> My goal was merely to argue that adding an origin/cookie check to a
> secret-token-based mechanism adds meaningful defense in depth, compared to
> just using any of the proposed protocols over UM. I believe my argument
> holds. If the secret token scheme has any weakness whatsoever, whether in
> generation of the tokens, or in accidental disclosure by the user or the
> service consumer, origin checks provide an orthogonal defense that must be
> breached separately. This greatly reduces the attack surface. While this may
> not provide any additional security in theory, where we can assume the
> shared secret is generated and managed correctly, it does provide additional
> security in the real world, where people make mistakes.
>

It seems like the fundamental disagreements here are:
- Cap proponents think that the ability to delegate is extremely valuable,
and ACLs provide too much of a barrier against delegation.  ACL people think
delegation is not as important as Cap people think it is.  Arguments either
way tend to be abstract, and thus unconvincing to either side.
- ACL proponents think that capabilities are too easy to leak accidentally.
 Cap people think that the defenses provided by capability design patterns
provide plenty of protection, but ACL people disagree.  Argument either way
again tend to be abstract, and thus unconvincing.

I guess it is an intractable argument.