[Telepathy] Fwd: GSoC Project: Add OTR support to Telepathy/Empathy for XMPP

[João Paulo Rechi Vita]

On Fri, Jun 3, 2011 at 13:12, Will Thompson
<will.thompson at collabora.co.uk> wrote:
> On 03/06/11 04:04, João Paulo Rechi Vita wrote:
>> I haven't thought that the UI could handle it entirely, it would be
>> pretty straightforward since it would need the code to trigger an
>> accept anyway. But wouldn't be easier to automatically test
>> (continuous integration) this feature in the CMs than in the clients?
>
> With the current test infrastructure, certainly. :)
>
>> Key verification is not a requirement for establishing the encrypted
>> channel, it just adds peer authentication. So the CM doesn't even need
>> to know if the user (not the client) don't recognize the key
>> fingerprint as being owned by it's conversation peer. In that case,
>> the may (or may not) just decide to terminate the OTR session, or the
>> even the conversation entirely. So "rejecting" the key would be
>> terminating the OTR session, and "accepting" it would be just
>> continuing it normally. I agree on having a property to store the
>> key's object path, and on that object we could store the key
>> fingerprint, the account it's tied to (maybe the account name should
>> be part of the object path), and it verification status. Key
>> verification (and thus peer authentication) can optionally be done
>> inside the encrypted channel using the Socialist Millionaire Protocol.
>
> Ah, interesting. So the CM negotiates the encrypted session without
> needing any input from the UI (except of course determining that it
> should establish the session in the first place), and verification-wise
> it's basically just relaying information between D-Bus and the network.
>
> Relatedly, in another mail, Christian wrote:
>
>> The only subtlety is ensuring that the user receives all the proper
>> notifications before it is possible for him to send messages over the
>> encrypted channel. i.e. while the CM is still in the "AUTHENTICATING"
>> state.
>
> So perhaps the CM should queue calls to SendMessage() while the
> encrypted session is being established, but once it has been
> established, it should allow messages to be sent even if the contact's
> identity has not been identified. Based on the above, the CM doesn't
> actually have to know about the verification state (correct me if I'm
> wrong). So this can be purely UI policy, since the UI has to know about
> this anyway.
>

Yes, in this whole key management and peer authentication matter, the
CM just need to receive the user key to input the AKE, pass the peer
key fingerprint to the UI, and provide an API to run the peer
authentication (which receives the shared secret as input).

>> The OTR protocol description calls "authentication state" each of the
>> steps of the AKE, which is the "handshake" of the OTR protocol. This
>> is not a very good name since it can be confused with peer
>> authentication, but it doesn't have nothing to do with peer
>> authentication. I think the state Christian and I called
>> "AUTHENTICATING" is the same you've called "in progress", which means
>> AKE has been started but not finished yet, so we're in the process of
>> establishing an OTR session.
>
> Okay, that's what I thought. Thanks for the clarification!
>

When writing down the whole API I've realized that "in progress"
should actually be broke down into tree states: REQUEST_SENT,
REQUEST_RECEIVED, and AKE_STARTED.

After finding my way through telepathy-spec XML syntax, I've managed
to write down whole API proposal and uploaded it at

http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/spec/Connection_Interface_OTR.html
http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/spec/Channel_Interface_OTR.html

I left key storage and peer authentication information storage
completely for the UI, that's why it doesn't appear on the proposal
above.

I've also uploaded my sketch of the state machine, since it may help
following the spec:
http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/state_machine.jpg

-- 
João Paulo Rechi Vita
http://jprvita.wordpress.com/