First cut at req and provide

[oskarth]

No description provided.

[decanus]

make ths imore explicit -> make this more explicit

[oskarth]

fixed

[cammellos]

They serve the same purpose, but MLS initialization keys do not provide plausible deniability

[oskarth]

Oh, had no idea, thanks!

[cammellos]

While this is strictly true, double ratchet is not a really a group algorithm, while MLS main focus is for group communications.

DR can be made to work for groups by pairwise encryption, and can leverage a broadcast channel for performance optimization, but you still would have to encrypt n times (you might not have to send n times if you have a broacast channel). Also partial sending is possible if not using a broadcast channel (I sent to n - 2 group members, rather then the whole group).

On the other hand MLS makes some tradeoffs in availability, not allowing group members who have not the most recent state to post to the group, while DR allows for that.

Overall DR seems to be a better fit for 1-to-1 and MLS (not surprisingly :) ) seems to be a better fit for at least large group chats, although there's seem to be a few issues that still would need to be ironed out, out-of-order messages not being supported out of the box, need to have the most up to date state to post to the group, how to propagate initkeys etc

[cammellos]

(just re-read the message, when I talk about MLS we are only talking about handshake/group-membership/key-update messages, not simple posts)

[oskarth]

You are right, worth re-emphasizing

[oskarth]

@cammellos Thanks for comments. What would you say are the requirements for Double Ratchet/X3DH on underlying layers? I.e. you need prekeys to support asynchronous, and gotchas around that. There does seem to be some other things as well e.g. in http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf (ctrl-f double ratchet)

I.e. out of order etc, but not clear on details. Do you know?

[cammellos]

@oskarth Signal's protocol would work in most condition, and does not have strong requirements on the layer below, works on datagram based or connection oriented just the same, and does not need broadcast/multicast, although it helps and offers some extra security properties (no ghost devices for example, like in our case).

Out of order and dropped messages can be handled always, but in the chart is marked as partial support as most of the implementations (including ours) will refuse to decrypt messages that are "too" out-of-order or if many messages have been dropped (we are talking about numbers in the 1000s, so if 2000 messages are dropped when sent from A to B, the 2001st message might not be decrypted, similarly for out-of-order).
The reason being is that both these messages can be exploited by a malicious user (for example by forcing the receiving user to ratchet many times, having to use a lot of CPU and storage).

Similarly to MLS in it's vanilla form it relies on always online storage that has certain properties (no stale reads for example, when it comes to distributing one-time pre-keys), if you want to keep the interactions to a minimum.

Without this (like in our case), there are no "one-time" pre-keys, so different strategies needs to be employed (in our case we rotate keys much more frequently, you can also have a one-time pre key per user, but I believe that's less effective, or force an extra round-trip etc).

[decanus]

"Detailed document outlining what each layer requires and provides" reads better

[oskarth]

ghost users

Just leaving it here we so we don't forget, this is an important point we need to look more into. https://keybase.io/blog/chat-apps-softer-than-tofu

also cc @corpetty fyi