Sorry for the brevity of my previous reply. I was traveling. I think the spec, as it stands, is a great start and more than enough to start coding from. But I think the handling of "OTR overtures" is poorly designed. I am talking about two components of the spec:
1) The AutoStart and AutoAccept flags. 2) The REQUESTED_RECEIVED (R_R) and REQUEST_SENT (R_S) states and the relevant methods/transitions. == (1) I brought up (1) a while ago. To discuss it in more depth: there are four possible states. Two of them are problematic: AutoStart On, AutoAccept Off Our CM automatically enters AKE when receiving a whitespace-tagged message. It automatically enters AKE when receiving a DH commit. It prompts the user (the client) when receiving an OTR query. This is silly. Why prompt in 1 out of 3 cases? AutoStart Off, AutoAccept Off Our CM ignores whitespace-tagged messages and OTR queries, but automatically enters AKE when receiving a DH commit. i.e. There is no way for a user to tell their CM not to automatically begin the AKE. That is Bad. The discussion becomes more problematic when we introduce OTR errors. If I understand your previous email, you want to automatically start AKE whenever you receive an error. I proposed an example fix for all this. There should be three bits. Enabled, AcceptWhitespace, and Prompt. I sketch their behavior below (I assume that everyone is using version 2. The behavior generalizes.) Enabled means that the CM is listening for OTR messages. When Enabled is on, we reply to error messages with a query (per the protocol) and we reply to otr queries (resp. dh commits) by beginning (resp. continuing) ake. We do not look at the AcceptWhitespace bit unless enabled is On. When AcceptWhitespace is on, we respond to white-space tagged messages with a dh commit. When Prompt is on, we prompt the user before sending a dh commit or accepting a dh commit. (This modifies the behavior of the above flags). == (2) The R_R and R_S states are buggy. The problem is that they are mutually exclusive and that they exclude other Message States (in particular, FINISHED). This immediately suggests a design flaw, because the conditions of "having received an overture" and "having sent an overture" are not mutually exclusive and do not exclude other message states. This design flaw translates into clumsiness during runtime. For instance: 1) In order: *Alice tells her client to begin OTR with Bob (Alice -> R_S) *Bob tells his client to begin OTR with Alice *Alice's CM receives Bob's query (Alice -> R_R because AutoAccept is off) and prompts Alice "Do you want to start OTR with Bob?" *Alice gets annoyed because this is what she just told her client to do. 2) Alice's conversation with Bob is in the FINISHED state. Bob sends her an OTR query because he wants to resume the conversation. Alice has AutoAccept turned off, because she wants to be prompted before sending dh commits. Thus her CM wants to transition into the R_R state. But it seems dangerous to leave the FINISHED state without input from Alice (it can be made to work by tweaking the underlying implementation, but this is an example of R_R being more trouble than it's worth). I propose getting rid of the R_R and R_S states and replacing them with this mechanism: *A method call RequestOTR that sends an OTR query and also sets the CM to automatically accept OTR overtures from Bob. *A signal called QueryReceived that lets the client know that Bob has tried to start OTR. == Other thoughts *The spec should state that when we leave the AKE_STARTED state because of AKE failure, we need return to PLAINTEXT or FINISHED depending on the state of the CM. i.e. OTR implementations must not go FINISHED ->(peer request) AKE_STARTED ->(failure) PLAINTEXT. This is obviously unsafe. christian On 06/09/2011 11:40 PM, João Paulo Rechi Vita wrote: > On Thu, Jun 9, 2011 at 19:42, Christian Anderson <[email protected]> wrote: >> Thanks for you clarifications! I will try to write a more in-depth reply >> later, but here are a few quick thoughts in case you're mulling over the >> spec as we speak. >> >> On 06/09/2011 06:18 PM, João Paulo Rechi Vita wrote: >>> On Wed, Jun 8, 2011 at 00:50, Christian Anderson <[email protected]> >>> wrote: >>>> On 06/04/2011 07:36 PM, João Paulo Rechi Vita wrote: > > (...) > >>>> >>>> Small questions: >>>> *Should PeerKeyReceived broadcast the type of the received key? Did you >>>> decide not to have d-bus objects corresponding to the keys? >>> The type of the key can be determined from the fingerprint. For now >>> I'm leaving key handling/storage entirely for the client, out of dbus. >>> When I get to the client coding part I'll check how to store it, but I >>> personally would like to have this stored in a common secure place, >>> like seahorse (for gnome), where different clients could share it. But >>> it's still something to be better analysed, since it should be >>> WM-independent and I don't know if freedesktop.org says something >>> about key storage. >> >> According to the OTR spec, a fingerprint is just a "SHA-1 hash of the >> byte-level representation of the public key". There's no way to figure >> out the original key type from a hash value. >> > > All right, just got confused with part that states that when using DSA > the leading zeros are omitted from the hash. Added the type argument > to that signal. > > (...) > >>>> *What happens if I call RequestSession while in the REQUEST_RECEIVED >>>> state and then realize I want to accept my peer's session request >>> Yep, rethinking it would be better to just ignore this method call on >>> REQUEST_RECEIVED, or return an error to the client. >> >> I'm not sure about that. I should be able to send OTR queries regardless >> of whether I have received them in the recent past. For instance, I >> might want to request different versions than the ones advertised by my >> peer. >> > > The protocol description is not very precise at this point, but taking > both points you raised into consideration, it seems to me both peers > can keep exchanging OTR query messages until one of them decides to > give and either accept or reject the request from the other. So the > original RequestSession description was correct then. > >>>> *What happens when I receive a session request while in the FINISHED state? >>>> >>> As stated in the protocol description, the only way to leave this >>> state is through an user action. So we should not automatically start >>> the AKE despite which policy is set. So we should act exactly like >>> when receiving it in the PLAINTEXT state without AutoAccept enabled. >> Maybe I'm confused. I thought that when we received an OTR query while >> in the PLAINTEXT state we transitioned to AKE_STARTED or >> REQUEST_RECEIVED depending on the value of the AutoAccept flag. My point >> was that it is unsafe to transition to REQUEST_RECEIVED from FINISHED. >> > > They only difference is that in the FINISHED state the CM will not > honor AutoAccept. > _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
