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

[Christian Anderson]

Thanks for you clarifications! I will try to write a more in-depth reply
later, but here are a few quick thoughts in case you're mulling over the
spec as we speak.

On 06/09/2011 06:18 PM, João Paulo Rechi Vita wrote:
> 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.

According to the OTR spec, a fingerprint is just a "SHA-1 hash of the
byte-level representation of the public key". There's no way to figure
out the original key type from a hash value.

>> *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.

OK, I'm not sure I understand the choice of these two properties in
particular, but it's not a correctness issue.

>> *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.

I'm not sure about that. I should be able to send OTR queries regardless
of whether I have received them in the recent past. For instance, I
might want to request different versions than the ones advertised by my
peer.

>> *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.
Maybe I'm confused. I thought that when we received an OTR query while
in the PLAINTEXT state we transitioned to AKE_STARTED or
REQUEST_RECEIVED depending on the value of the AutoAccept flag. My point
was that it is unsafe to transition to REQUEST_RECEIVED from FINISHED.

>> 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.
>
christian