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

[João Paulo Rechi Vita]

On Wed, Jun 8, 2011 at 00:50, Christian Anderson <christian at avtok.com> wrote:
> On 06/04/2011 07:36 PM, João Paulo Rechi Vita wrote:
>> 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
>>
>
> Thanks for the concrete proposal!
>
> Small questions:
> *Should PeerKeyReceived broadcast the type of the received key? Did you
> decide not to have d-bus objects corresponding to the keys?

The type of the key can be determined from the fingerprint. For now
I'm leaving key handling/storage entirely for the client, out of dbus.
When I get to the client coding part I'll check how to store it, but I
personally would like to have this stored in a common secure place,
like seahorse (for gnome), where different clients could share it. But
it's still something to be better analysed, since it should be
WM-independent and I don't know if freedesktop.org says something
about key storage.

> *Why are Versions and RequireEncryption duplicated on the Connection and
> the Channel but the other properties are not?

These are the only properties I think should be allowed to have
different values for different channels on the same connection.

> *I think you should specify the meaning of the boolean in the
> PeerAuthenticationConcluded signal.
>

Yes, I missed it.

> I also have a number of questions related to handling "OTR overtures".
> There are 5 ways that a peer, implementing the OTR spec, might initiate
> communication with us:
> 1. A whitespace-tagged message.
> 2. An OTR error message.
> 3. An OTR query message.
> 4. A DH-commit message.
> 5. Version 1 key exchange message
>
> You have introduced the states REQUEST_SENT and REQUEST_RECEIVED to give
> the client the freedom of accepting and rejecting sessions on the fly.
> Is it worth the extra complexity? Why not just handle each of the 5
> queries based on our channel's policies? As it stands, there are some
> issues arising from these two states. For instance:
>

This are only the states exposed to the client, so it knows what to do
when receiving a signal. I think it's necessary to add this ability to
the client to be able to honor the FINISHED state, as explained
bellow.

> *What happens if I call RequestSession while in the REQUEST_RECEIVED
> state and then realize I want to accept my peer's session request

Yep, rethinking it would be better to just ignore this method call on
REQUEST_RECEIVED, or return an error to the client.

> *What happens when I receive a session request while in the FINISHED state?
>

As stated in the protocol description, the only way to leave this
state is through an user action. So we should not automatically start
the AKE despite which policy is set. So we should act exactly like
when receiving it in the PLAINTEXT state without AutoAccept enabled.

> I think these states add unneeded complexity. I think they are logically
> problematic because it is quite possible for me to have both "SENT" and
> "RECEIVED" a request.
>

I think all of this situations can be worked out during the implementation.

> What I imagine as an alternative is handling each of the 5 overtures
> based on the policy flags that are set in the associated connection. I
> am still not sure how each of the 5 overtures is handled depending on
> the 4 possibles values of (AutoStart | AutoAccept). Could you specify
> exactly what those two flags mean?
>

1. A whitespace-tagged message.

If AutoStart, starts the AKE and transition to AKE_STARTED. Otherwise
do nothing and stay on PLAINTEXT.

2. An OTR error message.

If there is any version allowed (Versions is not empty), starts the
AKE. This is not explicitly exposed to the client.

3. An OTR query message.

If AutoAccept, starts the AKE and transition to AKE_STARTED. Otherwise
do nothing unless instructed by the client to do so (calling
AcceptSession).

4. A DH-commit message.
5. Version 1 key exchange message

Usually the peer wouldn't start the AKE without requesting it first
(but IIRC is not prohibited by the protocol). In these cases the CM
should react as stated on the protocol description, depending on its
AKE state (since internally, there will be all the states from the
protocol description). All corner cases that could arise in this phase
are previewed there.

Thanks for the feedback, I've updated the API description and will
upload to the same links.

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