Hi Paul!
You raise some valid points.
Am 24.02.21 um 01:37 schrieb Paul L'Allier:
*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.
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.
*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.
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).
Kind regards,
Paul
Kind regards - as well
Paul - as well ;)
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
