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

[Christian Anderson]

To reply to a question from earlier in the thread:

On 06/01/2011 01:04 AM, João Paulo Rechi Vita wrote:
> Yes, I think so. Essentially shared secret and question/answer is
> exactly the same thing, but on the latter there is a hint on which
> shared secret should be used for verification. This makes me think how
> does the question is passed to the other peer in a way it knows that
> it's a hint for him to set the SMP input. Any clues?

I don't see this discussed in the spec, but libotr supports bundling a
question with the smp initialization request. The relevant library
function is otrl_message_initiate_smp_q.

In response to the latest:

On 06/02/2011 11:04 PM, João Paulo Rechi Vita wrote:
> 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?

I don't think it makes sense to have a policy called AutoStart and one
called AutoAccept. Even now I have trouble keeping them straight. It
sounds from the names like AutoStart might aggressively try to "start"
OTR sessions, but this is false. Perhaps there should be a boolean
called AutoAccept = (WHITESPACE_START | ERROR_START) and a second
boolean called Prompt that indicates whether the user should be prompted
before starting OTR sessions (either because a request is about to be
AutoAccepted or because an explicit query has been received). I still
don't really see the need to support "Prompt" though.

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

I think that when presented with a new key, the client should have the
opportunity to reject it or ask for input from the user. Yes, the user
will know whether or not his channel has been authenticated, but there
are times when a key should demand the user's particular attention. If
Alice has chatted with Bob before and receives a key that is different
from the one that has been used in the past, she should probably be
explicitly notified of this, for instance. Requiring the client to
approve of a key before it is used to initiate OTR also opens the door
for richer key management schemes in the future. OTR keys could be
integrated with pgp keys, for instance (room is reserved for this in the
spec).

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

christian