Thoughts on droplets
Mark S. Miller
Mon, 01 Nov 1999 13:43:53 -0800
At 12:26 PM 11/1/99 , firstname.lastname@example.org wrote:
>Droplets is not the first system to use this kind of mechanism. While the
>specific encodings are different, the Lotus Domino server uses an
>essentially similar mechanism for naming Notes objects in web-based
>presentation -- even the format of the URL is highly similar. The Domino
>server, however, is not using swiss numbers; it's capabilities are purely
>object identifiers. Permission checking in Domino is done based on the
>session (and therefore on the user identity).
What are object identifiers? (I know too many definition to have any
confidence I know which one you mean.) Is Domino implementing a capability
system or an ACL system? Notes was (is?) heavily ACL oriented. If Domino
is doing capabilities without swiss numbers, how do they do three-party
handoff (the Granovetter diagram when Alice, Bob, and Carol are on 3
>It is not clear to me if Domino has session-only capabilities. If anybody
>cares I will try to find out.
I care, though more for curiosity than anything else. ;)
>Here I find that my initial impression of Droplets is correct, though I
>think my concerns could readily be addressed. Droplet capabilities are
>unforgeable, but they are not partitioned. Because they are simply data,
>there is no way to restrict their transfer once they escape into the world.
This is all exactly true for E/Pluribus's capabilities as well. My
falsifiable claim: any inter-machine "partitioning" protocol does not
enhance any actual security. These kinds of unpartitionable
data-capabilities implement the most capability security that can be
implemented in the distributed context. Machines cannot be confined
http://www.erights.org/elib/capability/dist-confine.html , hence, if I
understand what you mean by "partitioned", they cannot be constrained to
live in a partition either.
However, as explained by the above URL, computation (including distributed
computation) hosted on such machines can be confined, given the cooperation
of their hosting machine. To do this, you need a secure computing
platform, which E provides and Droplets currently does not, but none of
this requires or benefits from changes in the protocol.
It is crucially important for us to examine this claim well, and vigorously
try to falsify it, as it is a premise of E's security as well as
Droplets. A great way to attempt a falsification may be to propose a
protocol that claims to provide partitioning *in the protocol*, and see if
it actually provides any extra security.
> From my reading of the description at
>http://www.waterken.com/Droplet/index.html (which I may have understood
>incompletely), the session-independent capabilities remain valid
>independent of any particular session.
I will just speak for E/Pluribus here. Yes.
>On the one hand the droplet
>capabilities cannot be forged, but on the other they cannot be trusted as a
>means of security because there is no way to constrain their propagation.
>Once they are out in the world, one may safely attribute to them only those
>qualities normally attributed to object identifiers.
This sounds like the old capability-delegation argument all over again. If
I hand you my car key, you might duplicate it and distribute duplicates,
but that doesn't mean I can no longer have trust about who uses it or what
it may be used for. I can trust that it can only be used by entities and
for purposes that you enabled it to be used for. Therefore 1) I can trust
it to the extent that I trust you, and 2) I can hold you responsible for
the use made of it.
>I want to emphasize that this is a general problem in distributed systems,
>and that I am not aware of a satisfactory solution in the absence of a
>trusted operating system.
Depends what you mean by satisfactory. If satisfactory means confining
machines (or enclosing them in a partition), then you are
correct. However, a vast number of useful secure patterns of cooperation
without vulnerability, including most of the institutions needed to build
computational markets, can be done without confinement.
When Drexler & I were writing the Agoric Open Systems papers, before we met
Norm, we thought we had proven to ourselves that confinement and
abstraction were not simultaneously possible in a capability system. As a
result, the entirety of the agoric work back then assumed a world of
capability security without capability confinement. At machine
granularity, this remains the situation.
All the distributed capability architecture we did at the WebMart project
at Sun, and at EC Habitats at Communities.com relied only on capability
security without confinement or partitioning.
>Droplet's session-only capabilities, when running over an SSL link, provide
>a kind of partitioning for droplet capabilities, though hostile programs
>might still act from the client side by piggybacking on the session.
I didn't get this. Maybe I don't understand what you mean by "partitioning"?
>is a significant narrowing of exposure, and potentially very valuable.
>This is the part of Droplet that most appeals to me. The piece that seems
>to be missing is a private transform that will let me translate a new type
>of sessionless capability (let's call it an unauthenticated capability)
>into a session-local capability, and a corresponding public transform that
>will let me turn the session-local capability back into an unauthenticated
Dropping the qualifier "unauthenticated", E/Pluribus does have such a
transform. However, we think of it purely as a performance optimization,
and not something that contributes to any security properties. Of course,
I can't be sure that E's transform, though it fits the above words, is the
kind of thing you have in mind. How would such a transform provide any
>In its current form, Droplets has some potentially very useful properties:
>+ It can be used to selectively publish things on a server that otherwise
>contains private information (this is because of the swiss numbering)
>+ It can be used to extend the web URL space to generalized object
>identifiers (128 bits might be too small, but not because of security).
If 128 bits isn't big enough for any other reason, then it probably isn't
big enough for security. If 128 bits is big enough to make a random
collision infeasible, then what other problems might it have?