Thoughts on droplets

Mark S. Miller
Mon, 01 Nov 1999 13:43:53 -0800

At 12:26 PM 11/1/99 , 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 
separate machines)?

>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 , 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
> (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 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 
better security?

>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?