Droplets of understanding...

shapj@us.ibm.com shapj@us.ibm.com
Fri, 12 Nov 1999 14:28:07 -0500

MarkM and I had a long talk yesterday in which the source of my concerns
about Droplets security finally became clear.  I want both to explain both
why those concerns are valid in general and also why they probably should
not have been applied to Droplets.

MarkM pointed out to me that there is a difference of assumptions between
people in the crypto community and people in the OS community.  In the
crypto community, it is assumed that programs which handle sensitive
content are published and widely inspected, and that these programs can
therefore be assumed to behave as advertised in obeying the user's intent.
In the OS community, it is assumed that users run applications that are
unvetted on sensitive content.  While secure systems do incorporate trusted
applications, it is assumed that the cost of vetting applications in
general is impractically high.

The Droplets page, and Tyler's statements on this list, clearly specify the
assumption that the program is trusted to be well behaved, and that subject
to this assumption Droplets can make various security guarantees.  To me,
being on the OS community, this was sort of like saying "assuming we could
repeal gravity and turn day into night here are some nice things we could
do."  I now understand that in the context of the crypto community the
presumption of program trust may be a reasonable presumption.

For example, when Tyler has written words to the effect of: "If a
particular capability should not be transferred, then don't hand it out",
the OS security assumption set leads immediately to the conclusion that
this constraint is not in practice realizable even if the user is well

Now that this is clear, my remaining concerns are pretty minimal:

1. Droplets would benefit from a confinement solution.  Tyler is aware of
this, and I gather is working on it.
2. There is some room for concern that Droplets will get used for
applications where it's assumptions are not met, and that users will
believe that they are getting security out of Droplets even though the
program isn't trusted.  This is not a problem with Droplets, but I think
it's something worth being alert for.

I also want to add that I've let a few people within IBM know about
Droplets, and there has been some interest here in learning more about it.
I'll be trying to bring Tyler out to give a talk.

Architecturally, the only thing about Droplets I might still consider
re-examining is how sessions and session capabilities are handled.  The
current description makes it appear to me that the connection session (the
SSL connection) and the capability session (i.e. the context in which the
session capabilities are interpreted) are the same.  There are many
applications for which this association seems like exactly the right thing,
but there is no inherent reason why other relationships between connections
and capability sessions should be precluded.  In some cases, it might be
convenient for an SSL session to become associated with an already existing
capability session.  In others, it might be convenient to be able to drop
the connection, preserve the session, and be able to reattach to it later.

Thus, I suggest that the two ideas be architecturally distinguished. A
consequence of their separation is that I think "capability session" might
better be called "capability context" or just "context".  It seems clearer.
The current Droplets session capabilities then correspond to an application
where a new context is created for each SSL session and the context is
destroyed when the session is torn down.

Jonathan S. Shapiro, Ph. D.
Research Staff Member
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085  (Tieline: 863)
Fax: +1 914 784 7595