[Standards] XEP-0384: Staleness of devices

Philipp Hörist philipp at hoerist.com
Tue Aug 28 14:42:13 UTC 2018


Yes you can call this a Heartbeat message, but it doesnt solve the Problem
it only makes it less likely.

I as a client developer want to secure my users Communication, i cant
depend for that on other devices sending me Heartbeat messages and
advancing the rachet.
I always have to have measures in place when a device does not answer for a
long time.
This does not even mean the device behaves wrong, it could just be that it
is offline for a month.
If i dont stop encrypting to it after X messages, an attacker who gets a
hold of this device can decrypt all messages a full month back.

As for the question if an amount X should go into the XEP. I dont think
this is a good idea.
After how many messages you should stop encrypting depends on your threat
model, and how and for what you use the application.
500 could be way too much or a way too low number.
I think every application should set their own numbers.

Regards
Philipp

Am Di., 28. Aug. 2018 um 16:28 Uhr schrieb Jonas Wielicki <
jonas at wielicki.name>:

> Note, I’m not familiar with OMEMO and it’s ratchet system, so take this
> with a
> grain of salt.
>
> On Dienstag, 28. August 2018 13:26:51 CEST Paul Schaub wrote:
> > 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.
>
> Would it be possible for devices which exist and are used by a user, but
> not
> for sending (for whatever reasons) to auto-reply with an empty message
> with
> e.g. a probability of 1/10 or whatever to each message? This would allow
> advancement of the ratchet (If I Understand This Correctly) without user
> interaction and it puts the burden on the device which still wants to
> receive
> messages (i.e. if an attacker chooses to not send these messages, they’re
> hurting themselves).
>
> But yeah, I have no idea about OMEMO. Just throwing stuff in.
>
> kind regards,
> Jonas_______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180828/65cd2e4a/attachment.html>


More information about the Standards mailing list