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: standards-unsubscr...@xmpp.org
___
