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

[João Paulo Rechi Vita]

Hello all,

On Wed, Jun 1, 2011 at 01:20, Christian Anderson <christian at avtok.com> wrote:
> Thanks for your thoughtful replies. Comments inline.
>
> By the way, should we be continuing this discussion on the mailing list?
> Or did you intentionally take it offline? I can forward this same
> message to the mailing list unless you have reason otherwise.
>

Sorry for repeating almost the same message twice on the list. I was
planning to just fwd Christian's message and get some sleep, but since
I would be thinking about it for at least 20 minutes about OTR before
falling asleep, I decided to answer right away.

> On 05/29/2011 06:56 PM, João Paulo Rechi Vita wrote:
>> I'm not 100% sure how this verification relates to OTR, since it's not
>> mentioned on the protocol description [1], but it seems the
>> OTR-enabled clients implements it in a compatible way (at least I made
>> it work between pidgin and bitlebee). Pigdin offer 3 different ways to
>> verify your peer key's fingerprint: out-of-band manual fingerprint
>> verification, shared secret, and question / secret answer.
>
> I don't know the specifics of the Pidgin plug-in, but shared secret and
> question/answer are probably implemented using the socialist millionaire
> protocol.
>

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?

>> Since this verification ties key fingerprint to user account, even
>> with the possibility of keys being used between different accounts,
>> we'll have to keep an entry for each pair (account, fingerprint). I
>> agree fingerprint storage can be done on the client, that way the
>> client can even be smart to see that the same fingerprint is being
>> used for 2 different accounts and only ask the user if that two
>> accounts are owned by the same person.
>
> Yes! That's a very good motivation for storing key details in the
> client. And yes, something like (account, key type, fingerprint) is
> sufficient. No need to store the actual key data.
>
>>> On a similar note, the proposed spec stores OTR policy in
>>> Connection.I.OTR, but I think it might make more sense to have the
>>> client specify an OTR policy when creating a channel. The policy can be
>>> stored at the channel level. Let me justify this more after I discuss
>>> policy.
>>>
>>
>> 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) 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).

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

>>> The advantage of implementing policy at the channel level is that a few
>>> things work more naturally: One of them is AutoStart. Another is that
>>> the user can click a lock icon to indicate that he wants his chat with
>>> Bob to be encrypted. This toggles the channel state to
>>> REQUIRE_ENCRYPTION but doesn't transmit any data to Bob.
>>>
>>
>> I think you're missing some concepts too, REQUIRE_ENCRYPTION is a
>> policy. Clicking on a lock icon should trigger a call to the
>> StartSession method which would send an OTR query method to the other
>> peer. Or am I missing some use case here?
>
> We were just envisioning different things. I was imagining that clicking
> the lock icon would not result in a transmission. I see that this is not
> how the Pidgin OTR plugin works. Either way is fine.
>
>>
>>> I have taken the spec from your previous email and updated it below to
>>> reflect this new way of implementing policy. I have also tried to expand
>>> on the methods and properties of the channel to include everything that
>>> I think the OTR protocol requires. Whereas your spec hides the details
>>> of OTR beneath the interface, the below draft takes the other extreme
>>> and reveals most of them. It's just a draft that appeals to me and might
>>> not reflect the wisdom of what you guys have come up with separately.
>>>
>>
>> I just didn't understand the HandleKey() method you've proposed, but
>> maybe it have something to do with my initial confusion on keys vs
>> fingerprints verification?
>
> 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?

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

>>
>>> I included support for the socialist millionaire protocol as present in
>>> OTR version 3 (everything labeled SMP). But this support can be taken
>>> out without damaging anything else.
>>>
>>
>> Does supporting SMP means a new OTR version? From the protocol
>> description is seems to me it is part of version 2. I guess we should
>> tag the SMP API as "Future", so we can implement the OTR without SMP
>> first, and add it latter on (but I'm not completely sure on Draft and
>> Future tags meaning, can anybody help here?)
>
> I'm sorry, my language was confusing. SMP is included in the OTR version
> that we've both been referencing:
> http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html This is "v2" of the
> document and "OTR version 3.1.0" I believe.
>

I guess the OTR protocol version is 2, because of the policies
"AllowV2" and "AllowV1". I think this 3.1.0 comes from libotr's
version, which is currently 3.2.0.

> I'm excited by the progress on this! Thanks for all your work.
>
> christian
>
>>> ==ofdT.Channel.Interface.OTR
>>>
>>> This interface is only applicable to channels of type Text.
>>>
>>> -Methods
>>>
>>> StartSession ()          -> nothing
>>>  //Send an OTR query message on the channel
>>> EndSession   ()          -> nothing
>>> HandleKey    (b: Accept) -> nothing
>>>  //Called in response to the KeyReceived signal
>>>  //Lets the CM know if the key is accepted or rejected
>>>
>>> StartSMP     ()          -> nothing
>>> AbortSMP     ()          -> nothing
>>>
>>> -Signals
>>> MessageStateChanged        (u: State, u: Reason)
>>> AuthenticationStateChanged (u: State, u: Reason)
>>> KeyReceived                (o: Key)
>>>  //Broadcast during AKE when we receive the public key
>>>
>>> SMPRequested  ()
>>> SMPConcluded  (b: Success)
>>>
>>> -Properties
>>> Policy              u(Policy_Flags)         Read/Write
>>> Key                 o                       Read/Write
>>>  //The key that we use to identify ourself on this channel.
>>>  //Set by the client
>>> MessageState        u(Message_State)        Read only
>>> AuthenticationState u(Authentication_State) Read only
>>>
>>> SMPState            u(SMP_State)            Read only
>>>
>>> -Types
>>> Policy_Flags                Flags u
>>>  //ALLOW_V1, ALLOW_V2, REQUIRE_ENCRYPTION,
>>>  //SEND_WHITESPACE_TAG, WHITESPACE_START_AKE,
>>>  //ERROR_START_AKE
>>>
>>> Message_State               Enum  u
>>>  //PLAINTEXT, ENCRYPTED, FINISHED
>>> Message_State_Reason        Enum  u
>>>
>>> Authentication_State        Enum  u
>>>  //NONE, AWAITING_DHKEY, AWAITING_REVEALSIG
>>>  //AWAITING_SIG, V1_SETUP
>>> Authentication_State_Reason Enum  u
>>>
>>> SMP_State                   Enum  u
>>>  //EXPECT{1,2,3,4}
>
>



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