Hey all, since I haven't really responded to this yet on the list and recently there has been some discussions on the topic in the XSF MUC, I thought I'd give a short update. (This actually turned out much longer than I intended so skip to the second to last paragraph for a summary if you're pressed for time)
>> To get the ball rolling, I’ll play devil’s advocate for a bit here: it is >> impossible to implement OMEMO from scratch by the current documentation >> alone. >> “Axolotl” has no standard, and it appears Open Whisper Systems has no >> intention of writing one. The few bits of documentation and blog posts that >> we >> have are not enough to implement it and are outdated or wrong in some places. To give some context to those that haven't been following this in detail, there are two different versions of the TextSecure protocol that are currently relevant, v2 and v3. Axolotl was introduced in v2, v1 was OTR-based. There is publicly-available documentation of the cryptography[1] and wire protocol[2] used in v2. These are not exactly a standard, but do describe the protocol pretty clearly. Currently, the OMEMO ProtoXEP mandates use of v3. v3 introduced some variations on the underlying cryptography, along with corresponding changes of the wire protocol. Neither of those things are publically documented anywhere to the best of my knowledge. For this reason there has been some justifiable resistance towards OMEMO. I agree that this is a problem, and in light of this fact, I understand hesitation to proceed with standardization of OMEMO in its current form. I don't think that getting the Open Whisper Systems people to write up a spec of v3 for us is realistic, and I wouldn't feel comfortable with writing up this spec myself. What I propose is that we change the OMEMO spec to REQUIRE conforming implementations to support v2. We would further make it OPTIONAL to support v3 as well, as many client developers will likely re-use existing implementations of axolotl, most of which support both versions. The scenario of interest is establishing a new session. Let's say Alice wants to talk to Bob. Alice can discover whether Bob supports v3 by checking whether a signedPreKeyPublic and corresponding signedPreKeyPublicSignature are present in Bob's published preKeyBundle as these items were added in v3 (We might also explicitly announce v3 support in the XML here, I don't really feel strongly about this either way, although I don't think it's necessary). If Alice supports v3, and so does Bob, they can use v3 to establish their connection. If Alice supports v3, but Bob doesn't, Alice will realize this and fall back to v2. If Alice doesn't support v2, regardless of whether Bob does or not, Alice will simply ignore the signedPreKeyPublic and signature as she isn't aware of them, and establish a v2 session. Therefore, in this scheme we obtain automatic, transparent version negotiation (of sorts) for free. As a side-note on the cryptographic differences/benefits introduced with v3, there's not any documentation I could find that states the intent behind the changes. I won't speculate or make educated guesses as to the precise reasons at this time, but I will say that in any case, v3 does not appear to be less secure than v2, so allowing its use in an OPTIONAL fashion shouldn't decrease the security of the protocol. Further, distrusting clients can always chose not to announce support for it if they're dissatisfied with its unspecified nature. In conclusion, we can (mostly) resolve the standardization issues with axolotl using the previously described change, with no immediately obvious downsides. I would be interested in hearing some feedback on whether those parties previously dissatisfied with OMEMO for this reason agree that using v2 is a workable solution to the specification dilemma. In that case I would draw up the necessary alterations to the ProtoXEP. I would further be interested in opinions on the issue of whether the documentation that is available on v2 is deemed sufficient for an independent implementation, and if not, in what manners it is lacking, so please take a look! Additionally, there hasn't been much discussion about this on the list, so if there are any further grievances with OMEMO in its current state, please make yourselves heard, and maybe we can resolve those as well. :) Cheers, Andy --- [1] https://github.com/trevp/axolotl/wiki [2] https://github.com/WhisperSystems/Signal-Android/wiki/ProtocolV2 _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
