[Standards] Disappearing timers for OMEMO proposal

Alexander Krotov ilabdsf at gmail.com
Thu May 10 23:36:05 UTC 2018

On Thu, May 10, 2018 at 02:24:47PM +0200, Remko Tronçon wrote:
> > In federated environment you can't control what client is used
> > by remote party, and if it really does delete messages after timer expires.
> True, but it would still be a useful in a situation where you trust
> the other parties
> (e.g. non-federated setup where you know which clients are being used).
> And even in a non-federated environment, you can't be sure that the
> other side doesn't
> retain your messages, so there's always trust involved.

Agree. It does not matter whether environment is federated or not.

Even in non-federated setup, such as Signal, I trust my contacts
not to retain or publish messages I send to them. The client is
open source, it can be easily modified to ignore timers, but I can trust
my contacts not to do it. Otherwise I don't message them.

Same is true for federated environments. When using Email+OpenPGP,
people trust each other not to leak message contents and generate strong

> I don't see why a XEP for data retention hints needs to be tied to
> other XEPs like
> OMEMO, though.

When I send a disappearing message, I want it to be decipherable
only on devices that advertised support for disappearing messages.
Therefore, I will have to go into detail and specify that <key> tag,
which is specified in OMEMO XEP, must not be included for devices which
don't advertise timer support.

I also want to avoid dealing with the subtle relation between
"devices" and "resources" and think in terms of "devices" only, as
defined in OMEMO XEP. Thinking in terms of "resources" will likely
lead to some bug in timer setting synchronization protocol. Or,
even worse, delivering a disappearing message to device that does
not support timers, if some device advertises this resource as
supporting timers and another device which does not support timers
connect with the same resource later.

Also, disappearing messages implicitly rely on forward secrecy. It does
not make sense to implement disappearing messages for plaintext
messages, because messages can be retained on the server and it is not
trusted. What is less obvious, disappearing messages are not worth
implementing for OpenPGP, which does not rotate keys frequently.
If the keys are not rotated, messages can be retained on the server
until the key is leaked eventually. In this case, messages effectively
disappear only when you securely delete old private key.

The only other encryption scheme worth adding timers is OTR, but it can
use much simpler protocol. Advertise timer support on both ends and add
<timer> tag. There are only two devices, so start timer on the sender
immediately and on recevied when it is read.

If some encryption superior to OMEMO is developed later, it is
better to start from scratch and rethink all security considerations,
instead of trying to overgeneralize XEP now.

More information about the Standards mailing list