[e-lang] Re: Python, Twisted, Mont-E

[Mark Miller]

Allen Short wrote:
> Agreed. If WormholeOp is the best way to solve this problem, I believe
> we will soon have the tools to implement it.

I believe WormholeOp is indeed the best solution. It would be great to see it 
implemented!


> However, after discussing
> this issue with Brian Warner (the author of the new version of PB) and
> Zooko, we hit upon a scheme that seems too simple to be correct, but we
> can't find the problem with it: A sends a "make yourself available as"
> message with a nonce to C, then sends that nonce and C's Swiss number to
> B. B uses the nonce when retrieving the reference to C. If the nonce is
> not registered yet, B's request is queued. Since the nonce isn't
> registered until after previous A->C messages are received, C's vat can
> ensure that B can't send any messages to C until then.  As far as I can
> tell this doesn't fall into the DoS scenario because there is no need to
> block any other messages between vats.
> 
> This is very close to how E already does things, from the little I've
> read. What am I missing?

It is indeed extremely close to how E already does things. You're summary 
above is a bit confusing because it doesn't distinguish vats from the objects 
they host. Here's your text edited to match what E does:

> VatA sends a "make Carol available to VatB as" message with a nonce to VatC,
> then sends that nonce and Carol's SwissHash [a hash of the SwissNumber] to
> VatB. VatB uses the nonce when retrieving the reference to Carol. If the nonce
> is not registered yet, VatB's request is queued. Since the nonce isn't
> registered until after previous VatA->VatC messages are received, VatC can
> ensure that messages sent by VatB on this new reference aren't delivered to
> Carol until then.

Now I'm not sure if this last sentence is what you meant to say, but it's what 
E does, and perhaps it makes the issue clear. If the new reference obtained by 
VatB were a resolved reference, and if it was passed as an argument in a 
message from VatB to VatC, then it would arrive in VatC as a near reference to 
Carol, in which case something else in VatC could do an immediate call on it, 
affecting Carol before "prior" messages sent by VatA were processed.

If we substitute:

 > VatC can ensure that VatB can't send any messages to VatC until then.

then we'd have the documented DOS vulnerability: VatA can deny VatC's services 
to VatB.


>>Note that the web-calculus employs another way around the WormholeOp issue: 
>>forking a reference, by including it as an argument in a message to another 
>>vat, also gives it a new identity. I don't understand the implications of 
>>this, but I thought I'd mention it.
> 
> I don't understand how this gets around the problem either; even if the
> two references to an object are not EQ, how does that address the ordering problem?

I don't understand this anymore either. Tyler?

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM