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>. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
