[tahoe-dev] Invitation protocol

[Brian Warner]

On 7/11/12 10:01 AM, Michael Rogers wrote:

> If we can assume a bidirectional A-but-not-C channel (such as voice)
> for exchanging confirmation codes, we could use the following
> protocol, which is based on ZRTP's key agreement protocol:

That sounds pretty similar to Hoepman's A+A protocol, although his is a
bit simpler: Alice and Bob send short hashes of their ephemeral public
keys (after the commitment step, of course), rather than hashes of the
hopefully-shared session key. His protocol also sends the short hashes
before sending the full pubkeys, but I don't think that ordering
matters.

Both protocols allow two different UIs: either Alice types in the short
code she gets from Bob (and the agent decides whether to accept it or
not), or the agent displays the locally-derived code and asks Alice if
it matches the version she got from Bob (so she types Y or N). I always
prefer the former style, because in the latter, Alice is being trained
to just hit "Y" all the time instead of doing the comparison correctly.

> Unlike ZRTP, the use of two confirmation codes - one in each direction
> - prevents either user from skipping the confirmation step. But
> there's still a serious usability problem: how do you convince the
> users that they must use an authenticated channel, such as voice, to
> exchange the confirmation codes? If they use the channel they just
> established, or any other unauthenticated channel, the whole thing
> falls apart.

Yeah, there's interaction between that behavior and a use-case problem:
is this protocol being used to establish a *new* channel? Or to secure
an existing one?

OTR (as implemented in, say, Adium) is easier, in some ways, because the
humans have already indicated (in an insecure way) who they want to talk
to: you've got an IM connection already, the first phase of the protocol
locks that down, the second phase helps you decide whether your
locked-down connection is going to the person you thought it was. At no
point do you have to depend upon the crypto protocol to figure out which
IP address or screen name to talk to.

Likewise, ZRTP gets to rely upon human voice-recognition skills to get
"A"uthentication out of the crypto-established channel, effectively
getting an out-of-band -ish channel without previous setup.

I'm most interested in using the invitation code to also *establish* a
channel, since for things like Tahoe, there's nothing to bootstrap from.
If the Tahoe client were also an IRC client, or an MUA, then it could
quietly insert extra data into your IMs or emails to inform the agent on
the other side of its IP address/etc. But when it's a standalone
program, it's the human who gets the job of connecting agents together,
which puts more of a burden on the protocol, since asking the human to
transcribe an IP address and port number is boring and error-prone.


cheers,
 -Brian