[Standards] XEP-0384: Staleness of devices

Paul Schaub vanitasvitae at riseup.net
Tue Aug 28 11:26:51 UTC 2018

Hi everyone!

As some of you might know, the OMEMO protocol audit[1] from 2016
contained a notice, that stale devices might lead to loss of forward
secrecy. However, the XEP[2] has not yet been updated accordingly.

Stale devices are harmful for forward secrecy, as a device that only
receives messages, but never sends an answer back never forwards the
double ratchet of the sending device. The result is, that all message
keys are derived from one another, so breaking one message key more or
less reveals all following keys.

As a countermeasure some client implementations ignore stale devices
after a certain amount of time and stop encrypting messages for them.
However this can lead to deadlocks, as two devices which did not send a
message to each other for longer than the staleness period will consider
each other as stale and have no way to recover from this state.

In order to prevent this from happening, instead of deriving the
staleness of a device using time, clients could count how many messages
they sent to a device without getting a message back and derive
staleness from that counter. Eg. Alice could consider Bobs device as
stale after she sent n=500 messages to Bob without receiving an answer.
After receiving a message from Bob, Alice resets the counter to 0. An
appropriate value for n needs to be determined of course. Deadlocks can
then only occure if a huge amount of messages gets lost. Luckily this
does never happen with XMPP *cough*.

Another countermeasure against stale devices is sending empty
ratchet-forward messages on a regular basis. Those messages do have the
same format as KeyTransportMessages [3], in that they do not contain a
body. Their purpose is to forward the ratchet without user interaction.
The downside is, that a device has to do this on its own, so this is not
a good defense against attackers devices.

Still, do you think these things should make their way into the XEP?
What do you think would be an appropriate value for the staleness counter?


[1]: https://conversations.im/omemo/audit.pdf
[2]: https://xmpp.org/extensions/xep-0384.html
[3]: https://xmpp.org/extensions/xep-0384.html#usecases-keysend

More information about the Standards mailing list