[Standards] Disappearing timers for OMEMO proposal

Alexander Krotov ilabdsf at gmail.com
Sat May 12 22:07:32 UTC 2018


On Sat, May 12, 2018 at 07:55:52PM +0200, Paul Schaub wrote:
> Hi!
> 
> I get what you want to achieve, but I think it would be easier to define
> disappearing messages for general XMPP (not only OMEMO).
> 
> As already stated, you cannot trust devices that announce support, to
> actually delete messages after the timer expired.

I trust my contacts not to install broken clients. If it announces timer
support, I expect the client to respect timers.

> Lets assume you do
> trust all involved devices. Lets see how to deal with legacy devices.
> Why not specify ephemeral messages like this:
> 
> <message blabla="...">
>     <timer secs="300">
>         <body xmlns="jabber:client">This is an ephemeral message</body>
>     </timer>
> </message>

The idea to put timed message body in another element, analogous
to <encrypted>, is great, I am definitely going to adopt it. Thanks!
It will make it possible to implement unencrypted timed messages
for those who want it. This scheme will sort of work if both users
are running their own servers and that is the best we can achieve
for unencrypted messages anyway.

For unencrypted timed messages we need to require hinting the server
not to store the message, by the way.

> and in combination with OMEMO:
> 
> <message blabla="...">
>     <timer secs="300">
>         <encrypted xmlns="eu.siacs.conversation.omemo">
>             ....
>         </encrypted>
>     </timer>
> </message>

I would rather put <timer> inside <encrypted>, but since <encrypted>
is treated as <body> contents for OMEMO, we can go with unencrypted
timer setting for now. The only problem is that the setting is
exposed to servers. As for downgrade attacks, malicious server can
inject unencrypted messages anyway, so if it keeps resetting the
timer by injecting <timer secs="0">, you better just switch to another
server.

> That way legacy clients would not be able to display/decrypt the
> message, as they would not know how to deal with the timer element.
> 
> Let me know if there is something wrong with my idea :)

One problem I see is debug logs and clients that store raw XML of
<message> in their database, without removing unknown elements or
otherwise normalizing their structure. I am not aware of such
implementations, but we will need to check at least widespread open
source clients for this kind of behaviour.

I will still keep feature advertisement for OMEMO. Sending encrypted
messages inside <timer> to clients that don't support <timer> will
break double ratchet protocol. Sender will expect keys to rotate,
while receiver will ignore the message, and the session will break.


Lets also specify how timer setting synchronization will work for
encryption schemes that allow putting <timer> inside <encrypted>, such
as OX.

Client will maintain one "unencrypted" timer setting value, and one
setting for each E2EE scheme that allows encrypted <timer>.

Legacy clients will always omit <timer>, so for everyone else it will
look like user decided to disable timers. Sending a <body> without a
<timer> will reset all timer settings.

Unencrypted <timer> will set all timer settings to the same value.

Encrypted <timer> will set the setting for corresponding encryption
scheme, while keeping "unencrypted" setting intact.

If user switches from one scheme to another, and the "target" timer
setting does not correspond to the "source" timer setting, it will
set "target" setting to "source" setting immediately by sending an
empty <timer> message.


And, as a final note, lets rename <timer> to <ephemeral>. So we can
have <encrypted> <ephemeral> <message>.


More information about the Standards mailing list