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

[João Paulo Rechi Vita]

On Thu, Jun 2, 2011 at 14:58, Will Thompson
<will.thompson at collabora.co.uk> wrote:
> On 01/06/11 06:04, João Paulo Rechi Vita wrote:
>> On Wed, Jun 1, 2011 at 01:20, Christian Anderson <christian at avtok.com> wrote:
>>> On 05/29/2011 06:56 PM, João Paulo Rechi Vita wrote:
>>>> The problem is that Channels only exists for already established
>>>> conversations. The client needs a way to get/set the default policies,
>>>> that would be on the Connection object.
>>>
>>> If the client can get/set policies on a Connection object, why not just
>>> get/set them on each Channel? (There may be a very elementary answer to
>>> this, I'm just not very familiar with Telepathy). Are you suggesting
>>> having default policies on each Connection and specific policies on each
>>> Channel?
>>>
>>
>> Yes, default policies on each Connection object (one per Connection
>> Manager)
>
> A clarification: there is one connection per active connection to a
> server. For instance, I have three enabled XMPP accounts (my personal
> one, Facebook, and my Collabora account) right now; one copy of Gabble
> is running, with three Connection objects.
>

My bad, that was I first understood when studying the spec, but
completely forgot about this when writing the reply.

> When you set your status to Offline, there are no connection objects. To
> make these settings persist, you'd make them also be connection
> parameters with the DBus_Property flag
> <http://telepathy.freedesktop.org/spec/Connection_Manager.html#Flags:Conn_Mgr_Param_Flags>;
> Empathy's OTR preferences page would get and update their values on the
> Account object
> (<http://telepathy.freedesktop.org/spec/Account.html#Property:Parameters> and
> <http://telepathy.freedesktop.org/spec/Account.html#Method:UpdateParameters>
> respectively), and the Account Manager takes care of setting them on new
> and existing connections.
>

Understood, I'll update the proposal accordingly.

>> and specific policies on each Channel object. Note that
>> Channel objects only exists for ongoing conversations, that means most
>> of the time there will be no Channel objects around. Also, there are a
>> few things I think make more sense to be Connection-wise only (for
>> instance Advertise, AutoStart, and AutoAccept) since then should be
>> checked before the conversation starts (and the Channel is created).
>
> You want the channel to be created immediately, without waiting for
> network traffic, I think. This means the Empathy chat window can show
> the user what's going on, as in a throbbing padlock or something while
> the OTR session is initiated.
>

Isn't this the normal behavior for text channels? Does channels are
created when the user opens the IM window, or when she starts typing
(with the "peer is typing" notification message) ?

> I think it makes sense for the current OTR state to be properties on a
> channel interface, and also for the Connection to have a property for
> auto-starting OTR. This means applications requesting text channels
> don't have to care about OTR: they can request the channel, and the
> default setting will take effect. The preference has to be stored
> somewhere: it may as well be a account parameter/connection property as
> described above.
>

Agreed.

> I agree that Advertise :: Boolean lives on Connection.I.OTR.
>

Ack.

>>>> I agree there is some stuff missing, but just don't like exposing this
>>>> protocol-specific nomenclature to the clients.
>>>
>>> I don't know what "best practice" is. Not exposing protocol-specific
>>> nomenclature seems fine to me. How about something like:
>>>
>>> Enabled: Boolean. Must be true or we don't look at any of the other flags.
>>> SupportedVersions: String
>>> //"Enabled" and "SupportedVersions" combined gives ALLOW_VX
>>>
>>> AutoStart: (WHITESPACE_START_AKE | ERROR_START_AKE)
>>> Advertise: SEND_WHITESPACE_TAG
>>> RequireEncryption: REQUIRE_ENCRYPTION
>>>
>>> This is just a summary of your proposal except I left out AutoAccept.
>>> You're saying that the AutoAccept bit would determine whether or not we
>>> prompt the user when we receive an OTR Query Message? Is this necessary?
>>>
>>
>> Yes, that was exactly my idea regarding "AutoAccept". It's not
>> strictly necessary for OTR to work, but I think it could be useful and
>> will not add complexity to the API nor to the implementation. On the
>> same fashion, I'm not quite sure about the need for "Enabled", but it
>> wouldn't hurt. I'm personal feeling is that is better to have the both
>> of them in, since the worst that can happen is all clients always
>> setting them to True for all CMs.
>
> I guess it doesn't add much complexity to put this into CMs, and it
> makes the auto-accept logic much easier for the UI. My instinct would be
> to keep auto-accept in the UI, but putting it in the CM does sound good.
>

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?

>>> This could be my ignorance of Telepathy, but doesn't the client need
>>> some way to tell the CM that it has accepted a key? In particular, when
>>> Alice receives Bob's key during the AKE, her CM will hand it to the
>>> client (Empathy, say) and the client will have to determine how to
>>> handle the key based on the information that it has stored about Bob and
>>> based on its policy. For instance, it might just accept all keys. Or it
>>> might prompt Alice if this key has a different fingerprint from Bob's
>>> stored key. etc.
>>>
>>
>> Yes, after the AKE the CM should tell the client the fingerprint of
>> the key being used by the peer, so the client can react accordingly.
>> But isn't a signal be sufficient for that?
>
> There should be a property on the channel with information about the key
> (maybe the path to an object representing the key), and methods for the
> UI to call to accept or reject the key as appropriate.
>

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.

>>>> Also, I don't think the authentication
>>>> state should be exposed to the clients, since they wouldn't do nothing
>>>> useful with this information.
>>>
>>> Sure, but in that case there should probably be a new message state:
>>> PLAINTEXT, AUTHENTICATING, ENCRYPTED, FINISHED
>>>
>>
>> That's true.
>
> What do you mean by “authentication state”? OTR protocol details with
> more information than “not encrypted”/“in
> progress”/“encrypted”/“encrypted + authenticated” or so? Having that
> kind of information available makes sense to me; I agree that much more
> detail is likely to be ignored by clients.
>

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.

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