> On 23 dec. 2015, at 20:18, Andreas Straub <a...@strb.org> wrote: > >>> >>> 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!
Even for v2 I'm not convinced the existing documentation is enough to implement it. For example, the hashing algorithm used for the HKDF steps is not documented in either link you provided (sure, it's probably SHA-256, but it's an important detail). The documentation is also rather hard to follow, has irrelevant sections (SMS fragmentation) and lacks in argumentation for their choices. I would still prefer if some people wrote a specification for (or based on) axolotl that's self-contained and declared the authority for interop. OTR is 11 years old, so we really should aim to write something that can stand for a multiple decades. If at some point Whisper Systems stops updating libaxolotl and the repositories disappear and a new security issue is discovered then we still need to be able to understand it and investigate how to fix it. The Olm specification [1] is pretty close to what I would like to see (the level of detail, not the exact choices for cryptographic primitives). There may be some OTR or TLS people who are willing to help out here. > 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. :) Other comments: * I still prefer full-stanza encryption over just encrypting the <body>. Many XEPs such as XEP-0308, XEP-0301 and XEP-0184 become completely unusable when combined with only encrypted bodies. * I don't know whether PEP/pubsub adds this automatically, but I think it would be helpful if PreKey bundles contain a timestamp indicating when they were last updated, to make it easier for users to manage their devices. Regards, Thijs [1] = https://matrix.org/docs/spec/olm.html
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
