[Standards] Disappearing timers for OMEMO proposal

Alexander Krotov ilabdsf at gmail.com
Sat May 12 13:31:41 UTC 2018

On Sat, May 12, 2018 at 10:45:49AM +0200, Florian Schmaus wrote:
> On 12.05.2018 10:14, Alexander Krotov wrote:
> > On Fri, May 11, 2018 at 10:24:35AM +0200, W. Martin Borgert wrote:
> >> Quoting Alexander Krotov <ilabdsf at gmail.com>:
> >> Therefore it is orthogonal to any encryption and it does also not
> >> matter, whether your peer or one of your peers devices or resources
> >> does implement the feature or not. No need to check. As sender, just
> >> use the timers and let the problem of deleting messages to the
> >> recipient.
> > 
> > I want to be able to advertise to my contacts which of my devices
> > support timers, so devices that don't support them are not able to
> > decrypt the message.
> What prevents ("malicious") devices from announcing the feature and not
> deleting the message afterwards? What do you gain from coupling
> encryption and timers?

Nothing prevents "malicious" devices from announcing the feature
and not implementing it correctly. "Malicious" user devices are not
a part of my threat model. I have just explained it in detail in
another message.[1]

Announcing the feature is a way to tell my contacts that if they want to
send me an ephemeral message, they have to encrypt it only for those of
my devices that will delete them. For example, if I use a desktop client
that implements ephemeral messages, but still use a legacy mobile client
that does not, my contacts will only include a key for my desktop
client, and my mobile client will not be able to decrypt a message.

Coupling encryption and timers prevents plaintext messages from
being stored forever on *my own* legacy clients, so I don't have
to upgrade them all at once to make this feature works properly, and
my contacts don't have to worry if I have already upgraded all my
devices or not.

Even if backwards compatibility was not a problem, some client
developers may not implement this feature at all, for various reasons.
They may not be convinced that this feature is useful; they develop for
a platform that can't offer strong enough security guarantees (for
example, Web) and securely delete a message; they develop a new client
and don't have resources to implement full stack of XMPP extensions they
want at once.

> I feel like the answer is "next to nothing" but I'm happy to be told
> otherwise.

Well, hope I explained it clearly, thanks for open-mindedness. I
feel like broken snapchat threat model, with its "malicious users",
prevents the idea of ephemeral messages from gaining adoption.

[1] https://mail.jabber.org/pipermail/standards/2018-May/034925.html

More information about the Standards mailing list