Fw Number 3: [E-Lang] Bill Frantz saves the Stock Exchange
Mark S. Miller
Fri, 13 Apr 2001 18:28:36 -0700
At 03:44 PM Friday 4/13/01, Marc Stiegler wrote:
>From: "David Wagner" <firstname.lastname@example.org>
>> 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
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.