[tahoe-dev] Invitation protocol

[Brian Warner]

On 6/11/12 3:54 AM, Michael Rogers wrote:
> 
> You assume the invitation code remains secret until Alice and Bob have
> completed the protocol, but may be discovered later. Is that a safe
> assumption for email, IM, postcards, etc? Later, in the attacks
> section, you assume Mallory can eavesdrop on the relay to learn the
> channel ID. Why can't she eavesdrop on Alice and Bob to learn the
> invitation code?
> 
> Maybe an explicit adversary model would be useful.

Yeah, good points. My adversary model is this:

 * Alice and Bob have a single safe unidirectional 16-byte channel
 * Mallory runs the Relay
 * Mallory learns the IC after the protocol is done, not before

I assumed that Mallory can snoop the relay because it's at a
globally-known and fixed location: a nice juicy centralized target. Also
I'm trying to keep the relay out of the reliance set, so assuming that
Mallory can intercept+modify messages going through the relay is a
convenient proxy for the relay itself misbehaving.

Assuming that Alice and Bob have some way to transfer 16 bytes securely
is part practicality and part pragmatism. The practical part is that a
targeted attacker (one who knows Alice and Bob and specifically wants to
intercept their invitation exchange) has to watch them constantly, via
all conceivable transmission channels, waiting for that one moment to
strike. Since Alice sends her pubkey to the relay before sending her
Invitation Code to Bob, Mallory must have been watching the Alice->Relay
connection ahead of time (to read the key). There's a significant amount
of work to do, starting at an unpredictable moment, and very little time
to do it in. So it doesn't seem easy.

A non-targetted attacker (who's so lonely that they'd be happy to MitM
*anybody*'s connection, even complete strangers) could, say, grep the
IRC server feed for things that looked like invitation codes and claim
them before their intended recipient could. But if they don't know much
about the recipient, they probably aren't in a good position to MitM
their traffic, so the most likely attack they could mount would be
invitation-stealing, rather than MitM (Alice invited Bob but gets a
stranger instead who doesn't even know she's supposed to pretend to be
Bob, Bob gets an error and complains to Alice through their outbound
channel, Alice deletes the entry and tries again).

The pragmatic part is that, if Alice and Bob can't even manage to
transfer 16 lousy bytes without getting MitM'd, they're screwed anyways,
and no sensible amount of protocol cleverness can help them :-). I think
this situation is rare enough that there's value in providing for the
remaining environments.

cheers,
 -Brian