1629368 - consider how/if to warn when forward/reply encrypted email without encryption

Status: NEW

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Kai Engert [:KaiE:]]

With encrypted email it is easy to leak formerly encrypted information, by simply forwarding or quoting it, and sending it without encryption.

Alice sends a confidential message to Bob.
Bob considers it necessary that Carol is included in discussing the topic, clicks "reply", and add's Carol to CC. Thunderbird automatically quotes the contents of the original message.

Thunderbird can automatically enable/require encryption for a reply to an encrypted message. (We did this in the past for S/MIME.)

However, Bob doesn't have the necessary key to encrypt to Carol. Thunderbird prevents the message from being sent.

Bob is impatient, and disables encryption, allowing Bob to send the message anyway, thereby leaking the former message contents.

Another example is forwarding. Bob decides to forward the message to David. But David doesn't use encrypted email at all. Bob disables encryption and send it.

The suggestion is to develop UI to make it more difficult to reply or forward without encryption.

Here's an initial idea to solve this issue:

When replying to an encrypted email, don't quote any of the message contents. Start with an empty message. Potentially add a notification bar with text like "to avoid accidental leakage of the original message, it was not quoted. You may click the button to insert the quoted text anyway, but then Thunderbird will prevent you from sending this message without encryption."

If the user doesn't click and doesn't quote, then we allow the user to toggle the encryption state of the current message to "don't encrypt".

If the user clicks to insert the quoted contents, we will lock the require encryption setting for this message. We will disable the ability to turn encryption off.

When forwarding an encrypted message, we could also disable sending without encryption.

Is it acceptable to block users from replying/forwarding without encryption?
Some users will be thankful, but others might be frustrated when being blocked.

It we consider it necessary to allow users to reply/forward without encryption, then we wouldn't completely block the ability to disable encryption, but rather make it more difficult.
For example, when the user switches the encryption setting for the individual message, we could bring up a prompt. The prompt could explain what's happening. And disabling encryption should require more than just clicking OK. For example, toggling an additional control inside the popup dialog.

Thoughts?

Comment 1

[Kai Engert [:KaiE:]]

Another angle to consider:

It has been suggested to implement "automatically encrypt if possible". This won't be a feature of Thunderbird 78, but we're considering it for a future Thunderbird version. (See also bug 135636.)

The idea is, the user could opt in to automatically send messages with encryption, if valid keys for all recipients are available. If not, the message would be sent without encryption, without asking the user for a decision.

If Alice sent an encrypted message to Bob, then Bob doesn't know what Alice had intended.
Did Alice explicitly use encryption, because she consider the message contents highly confidential?
Or does Alice use a client that uses opportunistic encryption, and sent the message with encryption, simply because it was possible to do so?

Bob might not know if protecting the message contents is very important for Alice.

Let's assume we'll implement "encrypt if possible" at a later time, and Bob has that option enabled.
Bob replies, adds Carol to CC, and Carol's key is not available.
Based on the configuration, Bob's Thunderbird could automatically send the message without encryption, but not knowing Carol's intentions, Thunderbird probably shouldn't send without encryption.

I think the fix for this bug should include the future "encrypt if possible" scenario.

It might be OK to allow the "encrypt if possible" strategy for new messages.

However, when replying to an encrypted message, I think we should always make it difficult to reply/forward without encryption - even if Bob has the "encrypt if possible" choice configured.

Comment 2

[Selek Respa]

It might leak data but how about using WKD, DANE-OPENPGPKEY and DANE-SMIMEA and offer a key lookup for those people that you do not have a valid key for yet?

Comment 3

[Magnus Melin [:mkmelin]]

I'd suggest more or less wontfix for this. It's user choice. If it's really confidential, maybe it's better Alice notes that inside the message so Bob doesn't send it to people it shouldn't go to. Maybe we can have a notification bar that "The original message was encrypted, but it's now going to be sent unencrypted." But other than that, I'd not annoy the user.

Comment 4

[Kai Engert [:KaiE:]]

(In reply to Selek Respa from comment #2)

It might leak data but how about using WKD, DANE-OPENPGPKEY and DANE-SMIMEA and offer a key lookup for those people that you do not have a valid key for yet?

Selek, I consider that a separate topic. And it isn't guaranteed such lookups work. This bug is about the scenarios "it's impossible to find the key", or "a key was found but it's uncertain if the key is the right key", or "one of the recipients doesn't use encrypted email at all".

Comment 5

[Kai Engert [:KaiE:]]

(In reply to Magnus Melin [:mkmelin] from comment #3)

I'd suggest more or less wontfix for this.

Maybe, but I suggest to not close it immediately, but to keep it open to collect more thoughts and feedback.

Comment 6

[Alessandro Castellani [:aleca]]

I too think that we shouldn't change the UI or "make it difficult" to interact with a message based on its encryption status.

If the user specifically goes the extra mile to disable the encryption to forward/quote the message, it's something we can't go against it.

Maybe we could consider implementing a warning dialog, which is pretty disruptive on its own, when a user clicks forward on an encrypted message if the encryption was disabled, and adding a checkbox in the dialog with the usual "Do not show me this again".

But even that it seems a bit too much.
I'm also voting for a wontfix.