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

[Christian Anderson]

Thanks for working on this! I'm just an Empathy user who would like e2e
encryption, not an expert on anything. But I want to follow up on what
Will said and throw some ideas out there that might have already been
discussed out of band.

On 05/25/2011 02:24 PM, Will Thompson wrote:
> I'm inclined to think the key storage should be outside the CMs. There
> has to be UI for presenting keys to the user *anyway*. Plus, this allows
> the cache to work across protocols, if the same key can be used by a
> user for both their Jabber account and their MSN account, say. (Is this
> done in OTR? Or maybe keys are tied to the account.)

OTR keys can definitely be used between different accounts. I agree that
the should be handled outside the CM.

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.

Your three policy flags are Enabled, AutoStart and AutoAccept. Why not
directly support the policies from the OTR protocol [1]? These are
currently: ALLOW_V1, ALLOW_V2, REQUIRE_ENCRYPTION, SEND_WHITESPACE_TAG,
WHITESPACE_START_AKE, and ERROR_START_AKE. AutoStart could be
implemented at channel creation time by setting the REQUIRE_ENCRYPTION
flag on a channel if we have an OTR key stored for the handle we are
connecting with. AutoAccept could be implemented by turning on ALLOW_V*,
WHITESPACE_START_AKE, and ERROR_START_AKE. Your spec doesn't offer the
functionality of SEND_WHITESPACE_TAG which is important to OTR.

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

I've never worked with a D-bus before. Sorry for rookie mistakes.

[1] http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html

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}