Fw Number 3: [E-Lang] Bill Frantz saves the Stock Exchange

[Mark S. Miller]

At 03:44 PM Friday 4/13/01, Marc Stiegler wrote:
>From: "David Wagner" <daw@cs.berkeley.edu>
>> The load-balanced reference wasn't clear (sorry).
>> Here's my reasoning.  Real systems are going to want to do load-balancing,
>> probably.  So how will that work?  Probably the client will contact a
>> service which tells the client which server (i.e., which vat) to contact.
>> Maybe that former service is DNS, or maybe it's a dedicated load-balancing
>> service, who knows.  Then the client makes a vat-to-vat connection.
>> If, during the man-in-the-middle replay attack, the second connection
>> gets sent to a different server (different vat) from the first connection,
>> it seems to me you could be susceptible to replay.

First of all, I don't believe that E is vulnerable to "replay attacks" per 
se.  The MITM, having intercepted one (opaque to him) representation of a 
sent message, cannot cause that representation to be accepted as a received 
message multiple times or out of order.

The "attack" we're talking about, I think, a combination of two mistakes 
that Ppooko, who codes first, and never reads the manual, might very well 
make.  (Never mind the fact that we don't yet have an adequate such manual.  
We're not secure until we do.) 

1) I recently had a long phone conversations with Zooko, who explained that 
Ppooko would mistake a broken references for knowledge of lack of delivery, 
rather than lack of knowledge of delivery.  The MITM could exploit this 
misunderstanding by breaking the connection from Alice's perspective, 
causing Ppooko's Alice to engage in buggy recovery behavior, while keeping 
the connection open on Carol's side with the message delivery delayed as 
much as possible.  (The MITM can only do this until the next keep-alive 
timeout period, since it he can't fake one.  But if there's a vulnerability, 
this window should be enough to exploit it.)

2) Ppooko may very well assume much stronger ordering guarantees than E 
makes, such as full database-like global serializability.  For example, 
chronologically after Alice perceives the connect to be broken, if Ppooko's 
Bob queries Carol and finds that the message hasn't arrived yet, then Bob 
may consider it safe to resend the message.  This issue strikes me as 
possibly serious, as Bob's has easy no way within the semantics to verify 
that the message from Alice won't arrive.  (There are implementation 
specific techniques that would happen to work, but we know the problem with 
that.)  Note that Alice doesn't have this problem -- if she reconnects and 
queries Carol, earlier messages from Alice won't be honored.  (This is an 
intended part of the semantics, but is difficult to state.  It is correctly 
implemented though.)

A further form of attack we may be talking about is when Ppooko codes a load 
balancing network of vats to implement the Carol functionality.  I'm content 
to say that Ppooko isn't skilled enough to get that right.  Ppooko should 
stick with one vat per conceptual single service.


        Cheers,
        --MarkM