[Standards] Disappearing timers for OMEMO proposal
ilabdsf at gmail.com
Sat May 12 17:17:35 UTC 2018
On Sat, May 12, 2018 at 04:32:13PM +0200, Jonas Wielicki wrote:
> On Samstag, 12. Mai 2018 15:31:41 CEST Alexander Krotov wrote:
> > 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.
> Then I don’t see a reason to *require* a *specific type* E2EE. If you are
> worried about the server attacking, fine, use the <timer/> with OMEMO.
That I explained in another message too:
Ephemeral messages build on top of forward secrecy, and the only
other encryption scheme that has forward secrecy is OTR, but I don't
see any reason to prefer OTR+Timers over OMEMO+Timers. If any E2EE
superior to OMEMO is ever introduced, I would like to review timers
manually and apply them to this new encryption scheme, instead of
trying to overgeneralize XEP now.
Also, timer support announcement will depend on OMEMO. Feature
support must be signed in the same way prekeys are signed to prevent
malicious server from announcing it. It is impossible to define how to
do it without depending on OMEMO specification.
> > 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.
> See, this is extremely horrendous User Experience. One side of the
> conversation picks an encryption mode which makes messages only appear on a
> subset of the devices on the other side. People are already complaining about
> this with plain OMEMO, due to whatever-is-going-wrong (I’m not familiar with
> OMEMO on a development level).
Here is what will happen if I have a desktop (with OMEMO+Timers)
and a mobile phone (with only OMEMO):
1. My contact enables timers and sets timer value to 1 hour.
2. My contact client automatically sends an empty message with <timer> to update the setting.
3. My desktop changes the setting for this contact.
4. My mobile ignores the message.
5a. I write a message from mobile, it is sent without a <timer> and timers are disabled for everyone.
For my contact it looks like I have disabled timers and immediately sent a message.
5b. Alternatively, my contact writes a message, it is sent with <timer>.
Only my desktop can decrypt it.
I see its plaintext body (something along the lines of "this is an ephemeral OMEMO message").
I write back that I can't see it.
My reply does not contain <timer>, so timers are disabled for everyone.
In both cases my contact becomes aware I don't want to use timers now,
and timers are disabled automatically. No need to ask to disable timers
The only drawback is that in case 5b my contact has to resend the
message, because I can only read it on my desktop.
> (Then again, if we introduce a thing where having the message only on a subset
> of devices is a feature, we might use that as a diversion! /sarcasm)
Didn't understand it, sorry. Just in case, you can already modify
your OMEMO client to write messages that can be decrypted on a
subset of devices you choose.
> > 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.
> Why would your contacts worry?
If my contacts want to send me messages that I will delete, they need to
make sure all devices they have sent the message to support ephemeral
messages. Otherwise, I will eventually forget to delete the message on
some device or it will be stored in an insecure way (cloud, insecurely
deleted from SQLite database, unencrypted backup).
> In your other message, you explained:
> > In the part of my message that you quote, though, I was not even
> > talking about making sure message is deleted on a device that I
> > don't own, which is a matter of trust. I was talking about not being
> > able to decrypt the message on *my* devices by advertising that I
> > only want to receive ephemeral messages on some subset of my devices.
> So what is it now? Is this about data hygiene on your own devices (in which
> case we don’t even need wire format at all, just add a "delete last N hours"
> button, or if you want to default to deletion, add a "do not delete last N
> hours" button; actually, probably not the worst idea),
The option to automatically delete messages after some time period
is already available in Conversations, I have it enabled. But even
if I ask my contacts to do the same (which is very inconvenient
unless talking to another XMPP-enthusiast person), messages are
still stored practically forever on our desktops in clients which
store all messages without any way to periodically securely delete
them, such as SQLite database without secure delete flag.
> is it about data hygiene on other peoples devices and servers (E2EE not
> required at all to make this work, since it’s a matter of "trust" anyways;
> and I think this might actually be a useful feature sometimes),
It is a matter of trust, but I will never trust the server. Servers
are not going to implement secure deletion because it will impact
their performance. OMEMO allows me not to trust the server. I only
trust my contacts. The fact that it is a matter of trust does not
make me trust all parties involved at once or nobody at all.
> or is it about security and actually safely deleting timed
> messages (not possible, as you know)?
It is about security and actually safely deleting timed messages.
It is possible under the threat model I describe, where there are
no malicious users, i.e., if users trust each other, but not the
server. It is definitely possible for two parties to cooperate to
safely delete some messages after exchanging them.
I also don't see a contradiction between "data hygiene" and "security".
Data hygiene is a security feature. For example, securely deleting
DH keys is a data hygiene and it is the basis of forward secrecy.
Same for securely deleting message contents.
>I feel that you’re shifting goalposts all the time.
The goal is to be able to cooperatively agree with a trusted contact
that we want to delete some messages after agreed time period, until
agreed otherwise. The feature is here to make sure none of us forgets
to delete the messages from some device. It is a way to automate
this agreement, not to enforce it.
In ideal case we add timers support to all our clients eventually,
stick with some comfortable timer value (like a week or a couple
of days) and don't change it anymore. It will happen for some contacts,
but almost surely not for all, so we need to support heterogeneous
environments, where some clients are legacy.
When some clients are legacy, I want to be able to use timers
occasionally, when both parties use clients with timer support.
> > 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;
> Great, so now we have a subset of clients not able to receive messages from a
> subset of users who think that enabling timers by default is a good idea. And
> since your messages don’t arrive, you won’t know.
OMEMO clients send the same message, encrypted with the same ephemeral
key to all devices. They also include decryption keys for an ephemeral
key for each device. The only difference after enabling timers is
that keys for some devices will not be attached, so corresponding
devices will be unable to decrypt a message and display plaintext
<body> instead. Messages will not silently "not arrive" as you
And when you write any message back from a legacy device, timers
are automatically disabled until someone manually enables them, as
More information about the Standards