Ordering of messages in thread by client-controlled timestamp field

[anoadragon453]

Every MIMI content message has a timestamp {2} when the message was encrypted. It is represented as the whole number of milliseconds since the start of the UNIX epoch (01-Jan-1970 00:00:00 UTC).

The sort order for messages within a thread uses the timestamp field. If more than one message has the same timestamp, the lexically lowest message ID sorts earlier.

In a thread, the ordering of messages looks to only be determined by the timestamp field (other than when carrying out a tie-break). timestamp is a field controlled by the client that encrypts the message, and is hidden from the server. This implies that if another client receives a message that appears to be in the past, they have no method to prove otherwise. This can help enable social engineering attacks like the one below:

Group chat

1| Eve: Alice, are users allowed to post images in this room? <-- deleted later on
2| Eve: Alice, may I have access to the deploy scripts for the website? <-- inserted later on
3| Alice: Yes, that's fine Eve.

Alice<->Bob DM

1| Eve: Bob, Alice OK'd giving me permissions in room N. [link](link-to-group-dm)
2| Bob: Ack, adding you.

Is this specific to threads, or does ordering of messages in the room generally also only rely on the timestamp field? Can we use context from MLS to help with ordering messages, including in threads?

[rohan-wire]

Hi Andrew, We don't really have email-style threads in this document, just a topic ID. I think the ordering algorithm should be the same if you are in a topic or not. A topic is just a filter.

I meant to include a subsection about timestamp correlation in the Security Consideration section. I assume that the transport protocol will have some type of envelope franked with the arrival timestamp of the first server. If this server timestamp and the encrypted message both arrive at the receivers, they can compare the inner and outer timestamps and reject messages with inner timestamps that are too early or late.

[anoadragon453]

Comparing to a timestamp set by a server sounds sensible. Using only the first server may still leave room for malice by the server operator, though I'm unsure if that is in scope of our threat model.

Why not use the timestamp of when your server/the second server received the message instead? This would also prevent a remote server who's clock was significantly off from always appearing to send messages in the past, even when they were replying to the latest message in the room.

[rohanmahy]

From IETF 119 it looks like we have consensus to use the acceptance time of the hub when it is available to the client.