Element-web: 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?