On Fri, Jun 3, 2011 at 10:55, Christian Anderson <[email protected]> wrote: > I think we're at the point where it would be helpful to put forward a > proposal for the final spec. Joao, are you planning to do that? >
Yes, I'm planning to do so most likely tonight (UTC-3) or tomorrow the latest. > A few replies in line: > > On 06/03/2011 07:23 AM, João Paulo Rechi Vita wrote: >> On Fri, Jun 3, 2011 at 01:10, Christian Anderson <[email protected]> wrote: >>> To reply to a question from earlier in the thread: >>> >>> On 06/01/2011 01:04 AM, João Paulo Rechi Vita wrote: >>>> 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? >>> >>> I don't see this discussed in the spec, but libotr supports bundling a >>> question with the smp initialization request. The relevant library >>> function is otrl_message_initiate_smp_q. >>> >> >> Nice, thanks for the information. >> >>> In response to the latest: >>> >>> On 06/02/2011 11:04 PM, João Paulo Rechi Vita wrote: >>>> On Thu, Jun 2, 2011 at 14:58, Will Thompson >>>> <[email protected]> wrote: >>>>> On 01/06/11 06:04, João Paulo Rechi Vita wrote: >>>>>> On Wed, Jun 1, 2011 at 01:20, Christian Anderson <[email protected]> >>>>>> wrote: >>>>>>> On 05/29/2011 06:56 PM, João Paulo Rechi Vita wrote: >> >>>>>>>> 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. >>>>> >>>>> I guess it doesn't add much complexity to put this into CMs, and it >>>>> makes the auto-accept logic much easier for the UI. My instinct would be >>>>> to keep auto-accept in the UI, but putting it in the CM does sound good. >>>>> >>>> >>>> I haven't thought that the UI could handle it entirely, it would be >>>> pretty straightforward since it would need the code to trigger an >>>> accept anyway. But wouldn't be easier to automatically test >>>> (continuous integration) this feature in the CMs than in the clients? >>> >>> I don't think it makes sense to have a policy called AutoStart and one >>> called AutoAccept. Even now I have trouble keeping them straight. It >>> sounds from the names like AutoStart might aggressively try to "start" >>> OTR sessions, but this is false. Perhaps there should be a boolean >>> called AutoAccept = (WHITESPACE_START | ERROR_START) and a second >>> boolean called Prompt that indicates whether the user should be prompted >>> before starting OTR sessions (either because a request is about to be >>> AutoAccepted or because an explicit query has been received). I still >>> don't really see the need to support "Prompt" though. >>> >> >> What I proposed is AutoStart meaning "automatically request an OTR >> session when a peer advertises it", and AutoAccept meaning >> "automatically accept OTR session requests". >> >> What you're proposing is having AutoAccept to mean "automatically >> request an OTR session when a peer advertises it" and Prompt to "do >> not automatically accept OTR session requests". > > I think we're both confused about what the other person means. When you > make your idea concrete in a proposed spec, maybe it will turn out to be > what we both wanted the whole time :) > >> >> It's just a matter of nomenclature, right? From both proposals I still >> prefer mine, since it seems more clear to me (maybe just because it's >> how I thought of thinks from the beginning). If there is some >> practical non-subjective reason why one should be chosen instead of >> the other, I'll be happy to follow it, otherwise I may stick with the >> names I've proposed. Please don't take this as a matter of "mine" over >> "yours", in the end it's just naming and we should go over this to put >> efforts getting things done in Gabble / Empathy. >> >>>> >>>>>>> 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? >>>>> >>>>> There should be a property on the channel with information about the key >>>>> (maybe the path to an object representing the key), and methods for the >>>>> UI to call to accept or reject the key as appropriate. >>>>> >>>> >>>> Key verification is not a requirement for establishing the encrypted >>>> channel, it just adds peer authentication. So the CM doesn't even need >>>> to know if the user (not the client) don't recognize the key >>>> fingerprint as being owned by it's conversation peer. In that case, >>>> the may (or may not) just decide to terminate the OTR session, or the >>>> even the conversation entirely. So "rejecting" the key would be >>>> terminating the OTR session, and "accepting" it would be just >>>> continuing it normally. I agree on having a property to store the >>>> key's object path, and on that object we could store the key >>>> fingerprint, the account it's tied to (maybe the account name should >>>> be part of the object path), and it verification status. Key >>>> verification (and thus peer authentication) can optionally be done >>>> inside the encrypted channel using the Socialist Millionaire Protocol. >>> >>> I think that when presented with a new key, the client should have the >>> opportunity to reject it or ask for input from the user. Yes, the user >>> will know whether or not his channel has been authenticated, but there >>> are times when a key should demand the user's particular attention. If >>> Alice has chatted with Bob before and receives a key that is different >>> from the one that has been used in the past, she should probably be >>> explicitly notified of this, for instance. Requiring the client to >>> approve of a key before it is used to initiate OTR also opens the door >>> for richer key management schemes in the future. OTR keys could be >>> integrated with pgp keys, for instance (room is reserved for this in the >>> spec). >>> >> >> The peer's key is received during AKE, when OTR signaling has just >> been initiated. Also, according to the protocol description, peer >> authentication should be done inside the encrypted channel, so trying >> to do so before the AKE finishes and message state is ENCRYPTED would >> be deviating from the protocol. >> >> I totally agree that the client should warn the user in the event that >> an OTR session has just been established with an unauthenticated peer >> (that means we haven't authenticated the peer's key before), but a >> property with key information plus the EndSession() method should >> suffice to implement this behavior on the client. In the case you've >> described the client could notify the user that Bob's key is different >> from one previously seen and prompt if the user would like to start >> the SMP to authenticate the peer, finish the conversation, or ignore >> and continue encrypted anyway, but this is client's policy, so it >> should be left to them. > > The only subtlety is ensuring that the user receives all the proper > notifications before it is possible for him to send messages over the > encrypted channel. i.e. while the CM is still in the "AUTHENTICATING" state. > I understand your concern, and it's something we should definitely care about. > Thanks for all your work, And thank you for all your help! -- João Paulo Rechi Vita http://jprvita.wordpress.com/ _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
