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 behaved.
Now that this is clear, my remaining concerns are pretty minimal:
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