At 04:40 PM 3/6/00 , Ron Rivest wrote:
>(2) We went through the MintMaker and CoveredCallOptionMaker is some detail.
> It's nice that you can express the desired behavior (and implicit security)
> so simply.
Thanks.
> However, when we tried to figure out what is *really* happening,
> it became more difficult.
Well, from the rest of your question, you succeeded. With practice, it quickly stops being difficult as well.
> When one is trying to figure out what messages need to be sent between
> various machines (i.e. what the communications efficiency is), and
> when one is trying to assess the security implications of breaking into
> a single machine (or vat), it becomes important to have a feeling as to
> *where* various objects end up residing.
Agreed wholeheartedly wrt comm efficiency & availability issues. To our surprise, we found availability-under-partition to be a major driving factor in determining where to place which objects.
E's concurrency control http://www.erights.org/elang/intro/quickE.html
http://www.erights.org/elib/concurrency/index.html http://www.erights.org/elib/concurrency/vat.html http://www.erights.org/elib/concurrency/refmech.htmlcauses yet another semantic significance to the location of objects: objects within a vat can access each other synchronously (the "immediate call")or asynchronously (the "eventual send", written "<-"). Between vats, objects may only access each other asynchronously. Therefore, there is no foundational inter-vat atomicity. This restriction effects both the location of state and the design of object protocols. Among the benefits of this restriction? E is deadlock free (in a control-flow sense):
E's unit of atomicity is the "turn" or "event", and consists of the synchronous (call-stack-based) portion of the processing of the reception of an eventual send ("<-") to an object in this vat. Because vats only have asynchronous access to each other, each turn is isolated from all activity in other vats, and has no means to block on something outside the vat. But see http://www.erights.org/elang/concurrency/epimenides.html for the deadlock issue we get in exchange: "data-lock". As we expected, we have found data-lock bugs to be *far* less frequent than traditional control-flow deadlock bugs. (Note to Joule-ers: this is one area where E has a material technical improvement over Joule. E is much less vulnerable to data-lock bugs than Joule.)
As to security, I also agree, but much more weakly than you might guess. When Alice sends to Bob access to Carol, in what ways should Bob trust Carol? And how should Bob (or Bob's programmer) determine this? While it is true that Bob would be wrong to trust Carol more than he trusts Carol's hosting machine, strangely, Bob does not need to determine Carol's hosting machine (and in practice never does) in order to know what kind of trust to invest on Carol.
Starting only with the pure abstract capability computation model, the meaning of the message Alice sends to Bob, combined with the kind of trust relationship inductively required for someone (such as Alice) to become a client of Bob, determines what we should be able to say about the kind of trust relationship Bob should come to have, not with Carol per se, but the whoever is referred to in that argument position in this message when received by Bob in his current state. Since this argument was received from someone able to be a client of Bob (able to point at Bob), Bob would be wrong to trust this argument more than he trusts his clients.
With just pure capabilities, new trust is bounded by existing trust in just
this way. The Grant Matcher puzzle
http://www.erights.org/elib/capability/grant-matcher/index.html argues that
pure capabilities to be insufficient for some problems that intuitively seem
to be the kind of problems capabilities should be able to solve. The
introduction of a primitive symmetric equality primitive enables one to
solve the puzzle. Such an equality primitive uniquely allows one to combine
trust from two existing capabilities into a new one. Many actual capability
systems, including KeyKOS, EROS, and E, include such a primitive.
(Dean Tribble has shown, but not written down, a demonstration that pure capabilities + a rights amplification primitive (such as sealers/unsealers) is also sufficient to solve the Grant Matcher puzzle. Dean, care to explain?)
Conjecture: With the stipulation that the object creation primitive,
discussed in
http://www.erights.org/elib/capability/ode/ode-capabilities.html#begets
under "Connectivity by Parenthood" and "Connectivity by Construction",
necessarily creates the child in the same vat as its parent, then whatever
reasoning we would have engaged in above wrt the correctness of Bob
investing a certain kind of trust in Carol, still holds in the distributed
mutually suspicious machines case. E obeys this stipulation. As we say in
http://www.erights.org/elib/capability/ode/ode-protocol.html "This is the
main economy of the distributed capability model: we can, without loss of
generality, reason as if we are only suspicious of objects."
Pluribus, E's distributed object protocol, also supports distributed equality sufficient to support distributed Grant Matching, but this is not yet explained anywhere.
> For example, with the MintMaker example, it seems that all purses for the
> same mint presumably end up residing on the same machine as the mint.
> (I'm not sure if this is right; please straighten me out if it is not.)
Correct.
> This may be advantageous from a security point of view, as the sealer/unsealer
> never have to leave that machine. But it is disadvantageous from a communications
> point of view, as it means that the solution is really ``centralized'', with
> various parties have to communicate back to the central mint machine for each
> transaction.
Correct. But as Tyler pointed out, the result is very similar to what any clearing protocol for the transfer of exclusive rights would need to do.
> Perhaps such behavior is not required, but it is not obvious within your
> system as to how one can reason about or control such important system
> aspects as to where each object resides...
It is required, but the answer, explained above, may be so simple as to have been invisible. I hope this message clarifies the matter.
Throughout this message, please forgive me for fuzziness. I lack the formal tools or terminology to say the above precisely.
Cheers,
--MarkM