Re: comment on distributed capabilities

Thank you.  This is very helpful, and I mostly agree with it. 
> Even where you have trusted kernels, copy prevention may help prevent
> accidental leaks, but it can't really prevent attacks. (Suppose A
> shares a copy-limited capability X with an attacker B. B can share X
> with crony C just by setting up a proxy Y that forwards messages to
> and from X, and sharing Y with C.) Limits on copying only have
> significant effect in the total absence of side communication channels
> that would let B and C communicate, and that kind of confinement is
> too... confining to be useful in the computing contexts we've been
> talking about.

It's been a long time, but I'm pretty sure that the systems I worked on 
many years ago had just such limitations:  the only way to communicate a 
capability was to ask the (possibly distributed) trusted kernels to do 
that for you.  The rough analogy I'd use would be Unix file handles.  You 
can't get two processes working on the same file by using your own means 
to copy your open file handle to the other process.  You can't email it, 
put it on the clipboard, or even leave it in shared memory.  You can 
arrange to share access to a file object with the help of the kernel, e.g. 
by opening the file and then forking.  (As an aside, I actually worked 
many years go on a distributed Unix system [1], not the capability-based 
system [2] I've been mentioning, and it did all this stuff in a 
distributed way.  You could open a file, fork, and have the forked process 
pop up on another machine.  The open file handle capability would 
correctly be implemented and shared across the distributed system. 
Anyway...)

> Clearly this regime cannot apply in a web context where such 
> general trust isn't available: an attacker can just run a 
> kernel that ignores the directive not to copy.

I'm not completely convinced of that.  Or more specifically, right now, 
Web-keys depends on having most every user-agent, proxy, server, and maybe 
email system be suitably careful with URIs;  I think one can move to a 
regime in which only code that's specifically involved in accessing 
protected resources needs to be trusted.  That's a big difference. 
Certainly, you need trusted code at some of the nodes, but I think 
suitable use of encryption, signatures, and public-key systems can support 
the creation of systems in which the places where you care about copying 
of URIs are much more strictly bounded. 

Thought experiment: imagine that trusted code in my user agent created or 
got hold of a public/private key pair for me. When I establish my identity 
with the Google Docs server, that code helps me provide to them my public 
key, probably by posting it to them, as part of establishing my identity 
with Google.  In fact, we could publish public keys in a trusted 
directory, make them available via OpenID, etc.  If anyone cares, I could 
provide a certificate with the key, and that would allow Google to verify 
with some PKI provider that I am (more likely to be) the Noah Mendelsohn I 
claim to be. 

Continuing the thought experiment, Google would transmit through the Web 
(or email or other means) as a capability, not be the clear-text form of 
the proof of my access, but rather that proof encrypted with my private 
key.  You could encrypt the entire URI, but to make the whole thing more 
Web like, you could do it like this:

                https://docs.google.com/Doc?encryptedProofOfAccess
=1237ed8cb872d20848affec

Derefencing that URI directly would typically be a mistake.  Likely, 
Google would just return you some page saying:  "You seem to have 
mistakenly used the encrypted form of this URI.  The document you're 
trying to reference may not be for you."

The intention is that the trusted user agents software (with my private 
key) would know to decrypt that, to yield something like:

                
https://docs.google.com/Doc?docid=0AYOd4-51pI6HZGc0d2Q3N2RfMGYyZmZ0cGdt&hl=en

So, this goes part way to resolving the problem.  That 2nd URI does indeed 
need to be protected, but the intention is that it exists in clear text 
only in software specifically with knowledge of this idiom.  Presumably, 
such software will use only a properly certified HTTPS stack to ensure 
that the URI doesn't leak when used for access.  Crucially, this "clear 
text" URI would never be passed around as a means of conveying the 
capability from one entity to another.  It would be used only for access 
by a user that had possession of the necessary private key, and by Web 
software written specifically to access protected resources.

How does a user agent know to decrypt before dereferncing?  This is the 
exact analog of the TAG's XRI-in-http-uri debate.  One answer would be to 
register something like capabilities.org, and do this:

                
https://capabilities.org/docs.google.com/Doc?encryptedProofOfAccess=1237ed8cb872d20848affec

Suitably written user agents would recognize capabilities.org as special 
(just was we've proposed for XRIs, etc.), do the decryption, and map this 
to:

                
https://docs.google.com/Doc?docid=0AYOd4-51pI6HZGc0d2Q3N2RfMGYyZmZ0cGdt&hl=en


The above doesn't completely disprove your point, Jonathan.  There is 
still that step where we have to trust the HTTPS path, but that's only in 
the particular case of software that knows the new idiom, and we can 
reasonably set requirements on those nodes.  Nothing in this thought 
experiment depends on general restrictions on the copying or 
retransmission of URIs in general, or on user agents, server logs (except 
for on that particular HTTPs path), in general being secure.

Again, there are probably a variety of practical problems with this 
particular scheme.  Certainly, it depends on new software at user agents. 
True, but to get security with the web-keys proposal we're implicitly 
requiring that >all< user agents meet certain new standards, and even then 
we don't deal with things like the email case.

I intend this thought experiment only to prove that alternatives are 
possible in principle, not because I'm convinced exactly this particular 
proposal is practical.  My point is that  we shouldn't jump to the 
conclusion that web-key style solutions are the only ones possible, 
especially over time, and that it's premature to bend the existing rules 
of the Web to make webkeys more secure than they currently are.  I've 
already made clear that I have no objection to use of approaches like 
web-key in particular cases where those involved happen to believe the 
risks are low enough;  I do object to proposals to, at this stage, tighten 
the rules for management of URIs on the Web, in email, etc.

Noah

[1] http://en.wikipedia.org/wiki/LOCUS_%28operating_system%29
[2] 
ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/83/945/CS-TR-83-945.pdf

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Jonathan Rees <jar@creativecommons.org>
02/12/2010 10:14 AM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     www-tag@w3.org
        Subject:        comment on distributed capabilities


I wanted to recognize and address a point you raised on the call
yesterday, which is that "distributed capabilities" in the web-key
sense are not the same as "distributed capabilities" in the sense used
in some capability systems from the 1970s and 1980s. This is true. I
think you were referring to systems in which each node in the network
has a trusted capability kernel that all other nodes can trust. In
this situation it is possible to some extent to limit copying by
treating the right to copy as one of the rights controlled by
capability discipline. Clearly this regime cannot apply in a web
context where such general trust isn't available: an attacker can just
run a kernel that ignores the directive not to copy.

Even where you have trusted kernels, copy prevention may help prevent
accidental leaks, but it can't really prevent attacks. (Suppose A
shares a copy-limited capability X with an attacker B. B can share X
with crony C just by setting up a proxy Y that forwards messages to
and from X, and sharing Y with C.) Limits on copying only have
significant effect in the total absence of side communication channels
that would let B and C communicate, and that kind of confinement is
too... confining to be useful in the computing contexts we've been
talking about. Limits on the ability to copy individual capabilities
have fallen out of favor in the capability community, with attention
instead being shifted to more general mechanisms for leak control.
Because of the de-emphasis of confinement and copy limitation, many
people have been happy to drop the distinction between traditional
capabilities and string-representable keys and use "capability"
generically.

We could argue about what is the proper application of the term
"capability" but that's not important. I don't think anyone is trying
to pull a fast one by using the word "capability", but if it's a
sticking point for you we can agree to say that secret URIs such as
web-keys are used analogously with capabilities (as opposed to being
capabilities), or that the secret URI pattern is analogous to the
capability pattern (as opposed to being an instance of it).

The question of how easy it is to copy a key, either by mistake or by
attack or a combination, is relevant and we'll continue talking about
it.

Jonathan

Received on Friday, 12 February 2010 16:47:56 UTC