Warning "Encrypted by a deleted session"

[harmathy]

Description

Warning "Encrypted by a deleted session" is misleading.

Steps to reproduce

• login a new session via browser
• write message in an e2ee enabled room
• logout the session

The waring suggests, that something is wrong with the message. However, as stated in #13086 (in this comment), this seems not the case.

I was wondering if this information should be displayed for the user at all.

Version information

• Platform: web and desktop

For the web app:

• Browser: Firefox
• OS: Arch Linux
• URL: riot.im/app

For the desktop app:

• OS: Arch Linux
• Version: 1.6.0

[ghost]

I believe this makes perfect sense. At first I didn't know what it meant. But after reading from

(in this comment)

I understood the meaning of the message now. Kinda hard for new users to know. Maybe something that should be addressed in FTUE.

---

@jryans: Edited to remove link to unrelated issue
@me: Don't edit my comment. Go ahead and post your own comment. Just delete my comment if you have to touch it.

[MamasLT]

We have been discussing a bit about this, and decided to suggest that maybe a small exclamation mark (!) of green or yellow colour without a shield might, or perhaps just letter (i) be better to use within this context of INFO more than WARNING.

[brandoncurtis]

I also found this issue and #13086 because application context—specifically this warning shield—and what I know about encryption hygiene were in tension with regards to whether it is "safe" or "good" to delete old sessions.

A few points with regards to the security implications of session deletion:

1. A user deletes a session—i.e. revokes a session key—to indicate that the session will no longer be used. The most common reason for this is that a mobile device is retired, an app or browser or desktop configuration is wiped, an operating system is reinstalled, &etc.

2. Deleting a session has practical and security implications for a peer that sends messages to the deleted session. Practically, it informs the peer that the deleted session will no longer be a message recipient, and so it is no longer necessary to expend the resources to encrypt messages so that the deleted session can decrypt them. This also has the security implication that if the deleted session keys are ever recovered by a malicious party, they can't be used to decrypt messages created after a peer received notification that the keys were revoked.

3. Deleting a session has primarily security implications for a peer that receives messages from the deleted session. The security implication is that it is intended that the session keys were destroyed, so it should be assumed that future messages from these keys are not valid; they could be the result of the sending user mistakenly using a deleted session, but it is possible—and should therefore be assumed—that the keys are compromised.

4. If messages from a session and revocation events can be unequivocally ordered, then messages from a session key prior to revocation should be considered secure and messages subsequent to revocation should be considered insecure.

5. Is it always possible to unequivocally order messages and revocation events? I think that it should be, but I'm not exactly sure how session deletion is implemented. If I understand correctly, the double-ratchet mechanism allows unequivocal ordering of messages both within a session and across sessions; in that case, a session revocation indicates a particular ordering nonce where the session key becomes untrusted, and this can be used to set different visual indicators for pre-revocation and post-revocation messages. Please correct me if I'm wrong

A few points with regards to the selection of a visual icon to indicate messages tied to a deleted session:

1. Messages from a session post-revocation should definitely receive the strongest warnings possible. The red shield with the exclamation point is appropriate.

2. Messages from a session pre-revocation should not imply a security problem. The shield icon automatically implies security, so if a shield icon is used at all then it should be green; otherwise a lower-case i for information in a yellow non-shield icon, like a circle or a square, could make sense.

[caev]

I disagree that it makes sense to display warnings to all your peers when you follow the best-case of a covered use-case of cross-signing. This undermines the only purposes of cross-signing:

• increase security by eliminating warning spam.
• make the verification actions necessary to operating a warning-free room feasible and discoverable.

"Throw up our hands and let the users sort it out" was the status quo before cross-signing. User verification was effectively useless for >90% of the userbase.

There should be a strong presumption against warnings of any kind. In this case, I think there should be no change to the decoration on a past message received from a device with a valid session at the time it was sent unless the sender has disavowed that message. Strawman:

• user logs out of device: show no warning on messages sent before logging out.
• user deletes device B from the privacy page of device A: also show no warning. In reality, this is common.
• user deletes device B from the privacy page of device A, and answers [Yes] to a modal, "Device B won't be allowed to send verified messages as you from now on. Do you wish to warn peers device B might have been misused at some point in the past, for example because it was stolen?": show a warning.

I understand the middle case is controversial, but in a group setting it is certainly the right tradeoff. Until we burn down spammy warnings users will not be secure because they will continue to correctly view the overall security system as an infeasible joke. This is already well-studied in browser certificate warnings. Unlike browsers, we should probably aim to take less than two decades to accomplish sane exception handling.

I don't think it matters what colour the warnings are. Until the warnings are very rare they will be disregarded, no matter what their colour. If there is more than one warning colour, that's a strong sign the warnings are too spammy to contribute to security. Instead the overall use-case needs to be thought through, and the users guided so no warning exists when no attacker is present. Cross-signing doesn't deliver value unless this is mostly achieved, and in the case of this warning it isn't.

[pixlwave]

maybe a small exclamation mark (!) of green or yellow colour without a shield might, or perhaps just letter (i) be better to use within this context of INFO more than WARNING.

If this information needs to be shown to users, I definitely prefer this idea more than the red shield. I find the red shield conveys that something has gone wrong.

Edit: In fact, I'd probably prefer a grey !/i so long as the session had been cross-signed before deletion.

[rgpublic]

I'd vote for removing this info completely. I logged out and in and all my historical messages had that warning icon next to them => Massive information overload and a jarring visual experience. No way for the user to do anything about this, so if there's no action that users can take anyway, why warn them in the first place?

[waclaw66]

Exactly, I was concerned for the first time what is the problem, some security issue. If it's by design to get rid of old sessions and there is no harm to messages, why to even inform about this.
I like concept of Matrix and Element very much, but it's too geeky for common users, too much visible options.
I want to migrate from Signal, because it doesn't have web client and can be used only on a single mobile device, which is annoying. Unfortunatelly still don't understand what keys (recovery, room e2e) are important to backup, is there some documentation about that?

I'd vote for removing this info completely. I logged out and in and all my historical messages had that warning icon next to them => Massive information overload and a jarring visual experience. No way for the user to do anything about this, so if there's no action that users can take anyway, why warn them in the first place?

[Disquse]

If that's still being discussed, this warning should be removed completely as it makes no sense and even annoying end user. Perhaps one-time warning or maybe a "show always" setting.

[olmari]

I'm all in for having better ways to indicate this info to user, but this info needs to be shown somehow, and never be "not show it to user" as this is vital information. There has been some good suggestions in this issue how it could be improved. Either show messages normally timeline before key got rejected, if that can be reliably be known all the time, or if not possible, some less intimidating and/or specific indicator for exactly this happenstance.

[harmathy]

For me matrix-org/matrix-react-sdk#6119 would be definitely an improvement (and I could live with it as a fix for this issue). Considering @brandoncurtis comment I am not sure, however, if it fixes the core problem:

If a message from an already retired session is a security problem, then this case should be caught and a warning should be displayed. If that is no security issue, then the warning should be eliminated completely.

[olmari]

@harmathy The whole thing all this pondering hinges is that participants can't know why the session was retired... Bulk of the times it is just logged out sessions by user, but it could also be bad guy gotten into session and that is then dropped by proper user, in which case it is security issue of high importance, which is more or less the whole reasoning it shows as it shows.

I know this is still irritating to most of peoples, but at this very moment I don't know how it could be made any better... Only other thing in theory there could be an method which differentiates normal logout and dropping the session with other client, but that still doesn't exactly answer much anything about the reasons behind..

[caev]

Every security warning has a benefit in exposing security problems and a cost in creating warning blindness. The warning-blindness cost applies not only to valid warnings from the feature in question, but all security warnings throughout Element. It's a form of spam. This isn't a negligible cost.

What is the benefit we get in exchange for it? I understand not wanting to give up the feature, "other users are warned when stolen devices are disavowed," but I don't think Element currently has this feature because the warning that's supposed to provide it is almost entirely spam. Even if you only consider the warning's undermining confidence in itself, not its undermining confidence in Element's entire security model, the warning is basically totally undermined. The warnings appear in any room where people are changing devices (unless they aren't deleting their old devices).

The most secure way to use Element currently is to never delete old devices to avoid this warning. Coincidentally, that's how unsophisticated people tend to use it, and they end up with >20 devices associated to their account, most of them dead web logins, and a few abandoned phones.

One good (not "worse than nothing") feature implementation might need the sender to explicitly and ceremonially (modal warnings or something) disavow a device instead of deleting it to clean things up, and the disavowal would come with a timestamp enforced cryptographically by PFS or ratchet-chain or both somehow. User: "I disavow messages that were:

• sent by this device AND
• sent after this bad message here"

This could be implemented by adding a "review your recent messages" modal/wizard complex thing to the device-deletion path.

A good reason to delete a device is to stop it from sending future messages under your name if the device is recovered by an adversary un-wiped, or if an old backup of the device's durable storage is recovered by an adversary. A normal deletion is a special case, "I disavow all messages sent by this device after I deleted it." An emergency disavowal is "I disavow all messages sent by this device a little earlier than when I deleted it, and here is the first bad message."

A more cynical not-worse-than-nothing implementation would nag users to clean up unused devices and treat those deletions as ordinary, while continuing to (ab)use the normal deletion path as security-emergency disavowal and continue to mark all the messages the disavowed device ever sent as bad not just the ones in the ratchet after it turned evil. This would leave no outlet for people who "clean up" their accounts because they want to defang decomissioned devices immediately, but if there are so few of those users in the normal population maybe this is the right call, especially if we feel normal users ought to be nagged to clean up stale sessions for other reasons. I don't know how many manual-tidying users there are in the population.

[vintprox]

As people noted several times, too many warnings - and they'll work the opposite way. Perhaps, maybe they can be grouped by a thin bar instead of creating a visual rubbish with these multiple icons?

[olmari]

Content is provided exactly in the PR explaining what was done etc, no need to repeat everythign already existing there(?)

[vintprox]

Content is provided exactly in the PR explaining what was done etc, no need to repeat everythign already existing there(?)

Just saw it, nice! (Damn, what's with my eyesight today? Sorry.)

[NotThomasEdison]

I think the grey shield is an issue for deleted and unverified sessions.

For sessions that were unverified and deleted, the grey shield with "Encrypted by a deleted session" still shows. This should not be the case as the source is unverified.

[sergiomb2]

I'm so tired of this issue , wtf every time a newbie login this happens , this is an overkill feature

[harmathy]

This issue was seemingly reintroduced by the adoption of the cryptography module from matrix-rust-sdk #21972.