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