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

[Christian Anderson]

I think we're at the point where it would be helpful to put forward a
proposal for the final spec. Joao, are you planning to do that?

A few replies in line:

On 06/03/2011 07:23 AM, João Paulo Rechi Vita wrote:
> On Fri, Jun 3, 2011 at 01:10, Christian Anderson <christian at avtok.com> wrote:
>> 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.
>>
> 
> Nice, thanks for the information.
> 
>> 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:
> 
>>>>>>> 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.
>>
> 
> What I proposed is AutoStart meaning "automatically request an OTR
> session when a peer advertises it", and AutoAccept meaning
> "automatically accept OTR session requests".
> 
> What you're proposing is having AutoAccept to mean "automatically
> request an OTR session when a peer advertises it" and Prompt to "do
> not automatically accept OTR session requests".

I think we're both confused about what the other person means. When you
make your idea concrete in a proposed spec, maybe it will turn out to be
what we both wanted the whole time :)

> 
> It's just a matter of nomenclature, right? From both proposals I still
> prefer mine, since it seems more clear to me (maybe just because it's
> how I thought of thinks from the beginning). If there is some
> practical non-subjective reason why one should be chosen instead of
> the other, I'll be happy to follow it, otherwise I may stick with the
> names I've proposed. Please don't take this as a matter of "mine" over
> "yours", in the end it's just naming and we should go over this to put
> efforts getting things done in Gabble / Empathy.
> 
>>>
>>>>>> 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).
>>
> 
> The peer's key is received during AKE, when OTR signaling has just
> been initiated. Also, according to the protocol description, peer
> authentication should be done inside the encrypted channel, so trying
> to do so before the AKE finishes and message state is ENCRYPTED would
> be deviating from the protocol.
> 
> I totally agree that the client should warn the user in the event that
> an OTR session has just been established with an unauthenticated peer
> (that means we haven't authenticated the peer's key before), but a
> property with key information plus the EndSession() method should
> suffice to implement this behavior on the client. In the case you've
> described the client could notify the user that Bob's key is different
> from one previously seen and prompt if the user would like to start
> the SMP to authenticate the peer, finish the conversation, or ignore
> and continue encrypted anyway, but this is client's policy, so it
> should be left to them.

The only subtlety is ensuring that the user receives all the proper
notifications before it is possible for him to send messages over the
encrypted channel. i.e. while the CM is still in the "AUTHENTICATING" state.

Thanks for all your work,
christian