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

[João Paulo Rechi Vita]

On Fri, Jun 3, 2011 at 10:55, Christian Anderson <christian at avtok.com> wrote:
> 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?
>

Yes, I'm planning to do so most likely tonight (UTC-3) or tomorrow the latest.

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

I understand your concern, and it's something we should definitely care about.

> Thanks for all your work,

And thank you for all your help!

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