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

[Christian Anderson]

Sorry for the brevity of my previous reply. I was traveling.

I think the spec, as it stands, is a great start and more than enough to
start coding from. But I think the handling of "OTR overtures" is poorly
designed. I am talking about two components of the spec:

1) The AutoStart and AutoAccept flags.
2) The REQUESTED_RECEIVED (R_R) and REQUEST_SENT (R_S) states and the
relevant methods/transitions.

== (1)
I brought up (1) a while ago. To discuss it in more depth: there are
four possible states. Two of them are problematic:

AutoStart On, AutoAccept Off
Our CM automatically enters AKE when receiving a whitespace-tagged
message. It automatically enters AKE when receiving a DH commit. It
prompts the user (the client) when receiving an OTR query. This is
silly. Why prompt in 1 out of 3 cases?

AutoStart Off, AutoAccept Off
Our CM ignores whitespace-tagged messages and OTR queries, but
automatically enters AKE when receiving a DH commit. i.e. There is no
way for a user to tell their CM not to automatically begin the AKE. That
is Bad.

The discussion becomes more problematic when we introduce OTR errors. If
I understand your previous email, you want to automatically start AKE
whenever you receive an error.

I proposed an example fix for all this. There should be three bits.
Enabled, AcceptWhitespace, and Prompt. I sketch their behavior below (I
assume that everyone is using version 2. The behavior generalizes.)

Enabled means that the CM is listening for OTR messages. When Enabled is
on, we reply to error messages with a query (per the protocol) and we
reply to otr queries (resp. dh commits) by beginning (resp. continuing)
ake. We do not look at the AcceptWhitespace bit unless enabled is On.

When AcceptWhitespace is on, we respond to white-space tagged messages
with a dh commit.

When Prompt is on, we prompt the user before sending a dh commit or
accepting a dh commit. (This modifies the behavior of the above flags).

== (2)

The R_R and R_S states are buggy. The problem is that they are mutually
exclusive and that they exclude other Message States (in particular,
FINISHED). This immediately suggests a design flaw, because the
conditions of "having received an overture" and "having sent an
overture" are not mutually exclusive and do not exclude other message
states. This design flaw translates into clumsiness during runtime. For
instance:
1) In order:
*Alice tells her client to begin OTR with Bob (Alice -> R_S)
*Bob tells his client to begin OTR with Alice
*Alice's CM receives Bob's query (Alice -> R_R because AutoAccept is
off) and prompts Alice "Do you want to start OTR with Bob?"
*Alice gets annoyed because this is what she just told her client to do.

2) Alice's conversation with Bob is in the FINISHED state. Bob sends her
an OTR query because he wants to resume the conversation. Alice has
AutoAccept turned off, because she wants to be prompted before sending
dh commits. Thus her CM wants to transition into the R_R state. But it
seems dangerous to leave the FINISHED state without input from Alice (it
can be made to work by tweaking the underlying implementation, but this
is an example of R_R being more trouble than it's worth).

I propose getting rid of the R_R and R_S states and replacing them with
this mechanism:

*A method call RequestOTR that sends an OTR query and also sets the CM
to automatically accept OTR overtures from Bob.
*A signal called QueryReceived that lets the client know that Bob has
tried to start OTR.

== Other thoughts

*The spec should state that when we leave the AKE_STARTED state because
of AKE failure, we need return to PLAINTEXT or FINISHED depending on the
state of the CM. i.e. OTR implementations must not go FINISHED ->(peer
request) AKE_STARTED ->(failure) PLAINTEXT. This is obviously unsafe.

christian

On 06/09/2011 11:40 PM, João Paulo Rechi Vita wrote:
> On Thu, Jun 9, 2011 at 19:42, Christian Anderson <christian at avtok.com> wrote:
>> 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:
> 
> (...)
> 
>>>>
>>>> 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.
>>
> 
> All right, just got confused with part that states that when using DSA
> the leading zeros are omitted from the hash. Added the type argument
> to that signal.
> 
> (...)
> 
>>>> *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.
>>
> 
> The protocol description is not very precise at this point, but taking
> both points you raised into consideration, it seems to me both peers
> can keep exchanging OTR query messages until one of them decides to
> give and either accept or reject the request from the other. So the
> original RequestSession description was correct then.
> 
>>>> *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.
>>
> 
> They only difference is that in the FINISHED state the CM will not
> honor AutoAccept.
>