I think that, much of the time, in a journalistic setting, apps like WhatsApp are used to report. If WhatsApp is used to report conditions at an event of political upheaval in a totalitarian state - and the receiver isn't routinely and quickly replying, this is a damn serious problem.

WhatsApp seems to be built for a threat model where a single message (and you can think of a block of messages without reply as semantically equivalent to a single message, here) being compromised is no big deal; only a conversation being compromised is a problem.

If there are cases (like this) where a single-message compromise is a big deal, and WhatsApp cares about these cases, then the simplest solution would be for WhatsApp to add a preference in the client to switch on—as the article describes—a "blocking mode" for re-key notifications, where retransmissions aren't allowed by default.

And - as the article describes - such a blocking mode would immediately expose to WhatsApp which users had not enabled it, and who would therefore be safe(er) to MITM (because they probably don't verify key changes in any meaningful way).

why? The UI on the receiver end could show the warning, not the message, and in the dialog to the Whatsapp systems behave normally. In that way the user would be notified of rekeying, the MITM attacker wouldn't be notified that the user is security consious.

t0: Client A sends message (1) to Server for Client B

t1: Server sends message (1) to Client B

t2: Client B fails to decode message (1) due to an outdated key. Sends failure notification to Server

t3: Server sends rekey notification to Client A

t4: (usually <400ms or >1 second) Client A sends rekeyed message (1') to Server for Client B

For t4, if the Server notices the response from Client A came faster than a user could ever have seen and responded to a notification, it now knows Client A is more susceptible to a MitM attack. If, on the other hand, Client A takes an appreciable amount of time to send the rekeyed message (say, 1 second or more) then we know that either there was a network latency, or the user had to respond to a rekey notification before the message was resent. We should be more careful about launching a MitM attack on this class of user.

So, without changing the actual _actions_ that the Server sees, but just the pattern of the timing of those actions, we're still leaking important information.

Note: all numbers completely made up.

Thanks for the extensive answer, indeed if the receiver need to react than this is discoverable.

I was more thinking along the lines of discharging rekeyed messages and not showing the message at all to security conscious receivers. Whether this is behavior is good, I can not say, UX tests could give more insights.