On Wed, Jun 1, 2011 at 01:20, Christian Anderson <[email protected]> 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/ _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
