On Fri, May 11, 2018 at 10:24:35AM +0200, W. Martin Borgert wrote: > Quoting Alexander Krotov <ilab...@gmail.com>: > > Disappearing messages without end-to-end encryption and forward > > secrecy are useless at best. They give the user false sense of > > security. That is why Telegram implements timers for "secret" chats > > only I believe, as I said in the first message. > > I respectfully disagree. > > Timers (or "ephemeral messages") are not a security feature, but only > a means of data hygiene.
What I propose is a security feature that complements forward secrecy. Just like OMEMO clients make sure not to store ephemeral keys, OMEMO+Timers clients should make sure not to store ephemeral contents. > 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. Otherwise I will have to remove messages manually, and it is not always possible, for example if messages are stored in the cloud or locally in the SQLite database without SQLITE_SECURE_DELETE pragma. Implementing this in a way orthogonal to OMEMO encryption is impossible, because mechanism I propose must be aware of "devices" and "keys". I agree that unencrypted disappearing messages may be useful to someone, so the <timer> element itself can be specified independently, but for my proposal it is only a small part of the whole solution. What you suggest (send disappearing messages to all devices, whether supporting the feature or not) is called opportunistic security. It is similar to sending email messages encrypted to those contacts for which you have their public key and plaintext to those clients for which you don't. That is how "autocrypt" (https://autocrypt.org/) works, but it offers lower security guarantees. For example, it can't help against active attacker, because it is automatically disabled if unencrypted message is received. Opportunistic security in email world is a compromise required due to problems with OpenPGP web-of-trust model proliferation. OMEMO has much smaller problems, especially since "blind trust before verification" was enabled. I definitely want a strong non-opportunistic mode, in which it is guaranteed that messages are only sent to those devices that support encryption. Adding opportunistic mode may be possible, but I am afraid it will overcomplicate both the protocol and the UI. For example, support for timers in clients that don't support encryption will make it impossible to move <timer> element inside the encrypted part in the future: it will break timer setting synchronization. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
