Thank you Paul. On Wed, 24 Feb 2021 at 01:22, Paul Schaub <[email protected]> wrote:
> Why would carbons not work in that scenario? > > All publicly known implementations of OMEMO do exactly that; encrypt the > message for all recipient devices and let the server distribute the > messages via carbons. There is no need to reencrypt, as the message will be > decryptable by all intended recipients. Note that all devices receive the > same copy of the message. The OMEMO header contains message keys encrypted > for each recipient device. The recipient device picks the suitable message > key, decrypts it and uses it to get access to the payload :) > See https://xmpp.org/extensions/xep-0384.html#protocol-message_encryption > for the details. > I suspect this is my lack of familiarity with the delivery mechanism for XMPP messages across a series of federated servers. It totally makes sense that a message from [email protected] to [email protected] would be sent as a single message from montague.net to one of Juliet's devices at capulet.net, and the capulet.net server would be responsible for determining which other devices of juliet's to carbon copy it to. If montague.net did the distribution, potentially the same message would be transmitted multiple times, unnecessarily using up bandwidth. (Possibly, server side, things are smarter than that - not got that far into the server mechanics yet.) Because I'm thinking about a simplified case where all the users are on the same server or cluster of servers, I was thinking it's the sender's server that should do the copying - but actually that's also the receiver's server... At any rate, I suspect I just need to think through the logic a bit more and it'll make sense to me - you've certainly helped me get there. 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. > > That sounds like a solution. Actually, some clients already do exactly > this. I wonder why this was not documented in the XEP as I could swear it > was in there at some point :D > > There is another approach that aims to reduce stale message keys (see > business rules): > > When a client receives the first message for a given ratchet key with a > counter of 53 or higher, it MUST send a heartbeat message. Heartbeat > messages are empty OMEMO messages as per Sending a message > <https://xmpp.org/extensions/xep-0384.html#usecases-messagesend>. These > heartbeat messages cause the ratchet to forward, thus consequent messages > will have the counter restarted from 0. > > While this approach would not work for devices that are offline for an > extended period, it works for inactive online devices (like phones left > home over the vacation). > Thank you - I'd missed that part of the business rules. That makes sense. Would it be viable for the sending clients to stop sending messages to that device when the counter reaches, say, 60 and start building a local store of them (up to some storage and time limit, on a FIFO basis?). Then the messages could be sent once the DH ratchet step eventually occurs - possible only sending them by agreement from the receiving device. It would potentially work even if large files were transferred, since these would be stored, encrypted, on the distribution server (possibly as described in XEP-0454: OMEMO Media sharing) and the sending client would just need to keep a copy of the encryption key. That's probably OK since the sender already has a copy of the file anyway. Identifying which of those late-transmitted messages are catch up copies the receiver has already seen on another device and which are truely new might be an interesting challenge though. (I'm slightly wary of the situation where the sender sends a message or file and then deletes their copy in order to avoid having a local record, unaware that there's an hidden "pending" copy still on their device. I'm not sure how much of an issue that really is though - it seems pretty contrived.) Kind regards, Paul -- Paul L'Allier [email protected]
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
