Hello, I'm new here - my apologies if I ask some stupid questions or commit some terrible faux-pas. I've tried to do some searching on the mail archive with Google and not come up with answers to these questions / thoughts.
Firstly, thank you for developing all those interesting and thought-provoking XEP standards. I'm very interested in end-to-end encryption (who isn't?) and I'm trying to work through some implementation thoughts. The basic principles of XEP-0384 make sense to me, I think. Other than the learning curve, I believe I can implement it in the client I'm working on. However, on my "nice to have" feature list is multi-device support and, there, I'm running into a few issues fully understanding how carbons and MAM would help me there. *Background assumptions* At least as a starting point for my project, all the users are on the same server (or cluster of related servers for the same domain) and all are using the same client type (adapted for platform, but that I can trust to behave - bad-actors notwithstanding). So doing something not perfectly standard compliant is allowable (though possibly not on this mailing list...). Despite that, I think some of these questions could be applied to the XEP-0384 standard or a multi-device extension of it. *General message sending / carbon copy mechanism, including offline sending.* Consider that Alice and Bob each have two devices (say a desktop and a mobile, some of which may be offline at any given time). The most optimal solution I can see is that each sending client is responsible for encrypting messages for all the other devices of the two parties. For example, messages from Alice's mobile would be encrypted and keyed for both of Bob's devices and for Alice's desktop. Assuming that Alice's and Bob's devices are differently keys (which I think they have to be), the mechanism in XEP-0280: Message Carbons, where I believe the server is responsible for copying to the additional devices, doesn't work since it can't re-encrypt the messages. An alternative would be for Alice to send to Bob's primary device (however "primary" is determined, considering that both his devices might be offline when Alice sends), which would copy the received messages to his other device. Apart from the possibility of the primary device dropping offline and the secondary device being used by Bob next, that is also not great from a mobile bandwidth perspective. Manual syncing between devices potentially avoids bandwidth concerns but it's even worse from a user experience perspective. Is there a better option I should consider, or something in one of the standards that should really have considered? *Risk of "stale" DH keys* I also have a bit of a concern that, if Bob rarely bothers to pick up his messages on his desktop, there could be a lot of messages in the conversation chain all encrypted with the same pairs of DH sending and receiving chain keys - the symmetric keys would ratchet, but all the message would be appearing to come from one party. If the encryption key on Bob's desktop was then stolen, an attacker would have access to all of Bob's messages (sent and received) for a potentially significant period of time. I guess this is actually little worse than a group chat situation where one of the participants isn't really participating - their keys would also give access to a significant section of conversation history. The possible mitigation there being that users probably have slightly lower confidentiality expectations for a group chat than a one-to-one, maybe. Some possible, though less than optimal options might be: - for the server to delete stored messages that go undelivered for too long (though this wouldn't protect against an actively monitoring attacker who had already stolen the keys). - for the sending client to put a limit on the number of symmetric key ratchet steps that would be allowed between DH steps and stop sending messages to the dormant client after that point. Again, have I missed a clearly better solution? Or am I concerned about something that isn't really an issue? Or maybe "loss of keys" just breaks open access to all future messages and I've misunderstood the meaning of forward secrecy. I'm drifting towards the conclusion that single user multi-device might be too problematic to implement from a security perspective - so I might have to restrict each user to a single device (which would likely drive some of them to create multiple accounts and group chat with all their devices anyway, so possibly that also isn't a solution.). Kind regards, Paul -- Paul L'Allier [email protected]
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
