[Telepathy] Fwd: GSoC Project: Add OTR support to Telepathy/Empathy for XMPP
João Paulo Rechi Vita
jprvita at gmail.com
Tue May 31 21:29:02 PDT 2011
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.
>
It was an accident, discussion should definitely continue on the
mailing list. Forwarding it now.
> 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.
>
>> 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?
>
>> 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?
>
>>> 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.
>
>> 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
>
>>
>>> 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'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/
More information about the telepathy
mailing list