Re: [UMP] Proxy-Authorization

On Tue, Jan 12, 2010 at 12:29 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Tue, Jan 12, 2010 at 10:51 AM, Tyler Close <tyler.close@gmail.com> wrote:
>> It's not feasible to remove all ambient authority. For example, the
>> client has the authority to send requests from its IP address. So we
>> draw a line between network connectivity and issued credentials. Proxy
>> credentials provide network connectivity.
>>
>> Also, as a practical matter, disallowing Proxy-Authorization might
>> inhibit use of UMP, since a resource author would be concerned about
>> the loss of users who are required to use a proxy.
>
> RIght, this is the essential point: whether we should remove a piece
> of ambient authority is a risk management decision.  Instead of
> dogmatically stomping out all forms of ambient authority,

Are you really accusing me of being dogmatic, or is this just more of
your hyperbole? Your arguments are frequently misleading because their
reasoning relies upon your use of hyperbole. In this case, by
characterizing my argument as dogma, you avoid addressing the
distinction I've drawn between network connectivity and credentials
issued by a resource host. I think it's a principled and useful
distinction and have explained why. Instead of logic, you respond with
hyperbole.

> we ought to
> weigh the costs of removing the authority (in this case compatibility
> issues with existing proxy deployments) with the benefits (greater
> resilience to a class of vulnerabilities).

Absolutely, and I and others commonly do so. For example, the Caja
language also gives careful consideration to what permissions are
ambiently available to Caja objects. In Caja, permission to consume
memory and CPU cycles is ambiently available to objects within a
particular Caja container. This makes a Caja container vulnerable to
DOS attack by a Caja object in that container. Similarly, the UMP
makes network connectivity ambiently available to clients that are
able to issue network requests. Just as Caja deems it too awkward to
deal with DOS at the granularity of individual objects, UMP deems it
too awkward to deal with network connectivity at the granularity of
individual requestors within a user-agent instance. In both cases, the
issues can be addressed at a coarser level of granularity, by
respectively placing memory limits on the Caja container, or not
giving proxy credentials to the user-agent instance.

> The reason we have different beliefs about whether CORS or UMP is a
> better protocol is because we perceve the risks and rewards
> differently.

I wish that were true. It would make for a more productive discussion.

>  Ultimately, authors are in a better position to weigh
> these factors than we are, which is why we should provide both APIs.

One of the problems here is that authors don't get to choose the
security model for their code, but are constrained by the choice made
by resources that they interact with. If you host a resource that uses
the CORS security model, then my client code must work within that
model. This is especially onerous, since under the CORS model, it is
the client code that is vulnerable to CSRF-like attacks, not the
target resource. In other words, if you choose the CORS model, then
any CSRF-like vulnerabilities in my client code are my problem, even
though the CORS model doesn't provide me a way to feasibly defend
myself against these vulnerabilities.

The security model is contagious. Even if we put out two APIs, one
will become dominant. Hopefully the continued lack of cookies in
XDomainRequest will sufficiently predispose the market towards UMP, so
the confusion caused by standardizing two security models will
ultimately have little effect.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Tuesday, 12 January 2010 21:59:50 UTC