Allow permanent decryption of OpenPGP/S/MIME messages when stored in local folders
Categories
(MailNews Core :: Security: OpenPGP, enhancement)
Tracking
(Not tracked)
People
(Reporter: KaiE, Unassigned, NeedInfo)
References
Details
(Whiteboard: project-tracker)
I've verbally received the following enhancement request.
Allow Thunderbird to configure local POP folders as "automatically store messages decrypted".
It could work in the following way: The user could be allowed to set a property on a POP folder.
If a message is delivered to the local folder, nothing is done yet automatically. This is best, because at the time of delivery, the decryption keys (which could be on an external token that's currently unavailable or locked) might not be available at that time.
However, at the time the user successfully decrypts the message for the first time, TB could automatically replace the message inside the local POP storage with the decrypted copy.
(This feature request is explicitly limited to POP and local folders, and doesn't cover IMAP folders, it seems wrong to automatically remove the encryption layer, if the message is still stored on a server. The reason is that a local folder could be covered by full disk encryption of the user's computer, while an IMAP server most likely doesn't have storage encryption controlled by the user, only.)
Reporter | ||
Comment 1•2 years ago
|
||
One detail that I'm worried about in this scenario:
The information, that the message was originally encrypted, would be lost. If the user tries to reply to the message, or forwards the message, TB would no longer know that the conversation participants might expect that this conversation is supposed to be confidential. Unless the user has a configuration that enforces encryption for all messages, the user might accidentally use cleartext for follow-up messages.
Reporter | ||
Comment 2•2 years ago
|
||
See also bug 1627962, which also suggests automatic decryption.
However, automatic decryption in a filter is difficult, because the decryption key might be unavailable at the time the filter is executed.
I think it does not make much sense if Alice sends super confidential mail to Bob e2e-encrypted and Bob is not really aware of the confidentiality and TB must prevent him from forwarding the mail or answering to it or cite it unencrypted.
I think it is up to the communication partners to agree on handling of confidential mails, e.g. agree on a special subject tag or something.
I think sending confidential content that receivers shall not forward (unencrypted or e.g. encrypted but to third parties) would only make sense e.g. with a email protocol extension for mails that have a "read-only" flag set (so no reply or forwarding) and destroy themselfes e.g. 5 minutes after being read.
Maybe for more serious confidentiality mail, Alice shout write a sealed paper letter to Bob.
Comment 4•2 years ago
|
||
I believe pretty strongly filters are the solution to this. It's a configurable solution that lets everyone store messages the way they need. If it seems difficult, it's just a matter of working on the UX for setting one up.
Let's not make assumptions that people using IMAP would not like to store decrypted, or how people want their data treated. It all depends on the user circumstances - and it's their data. You could have good reasons to trust your imap server. You could need to decrypt since you need to transfer e.g. a project folder of encrypted emails to someone else as you change jobs. Maybe you only want to decrypt permanently things from particular users (say encrypted emails about your bills). Any number of reasons.
But in general people would obviously have to opt in for a certain criteria. Filters allow you to do that.
However, automatic decryption in a filter is difficult, because the decryption key might be unavailable at the time the filter is executed.
You could just add a filter "when" hook to run it on decryption.
As I am the person that had the discussion about this with Kai at the GPGSummit, I want to elaborate a bit on the request (especially on possible solutions that came up in discussions with other participants of the meeting):
The request is not necessarily about storing the emails decrypted, but to decouple encryption from the original GPG key used to receive the email. I have encrypted emails starting from 1998, and newer ones are mainly generated and stored on tokens. Keeping all tokens accessible (even tokens for revoked/expired keys) is a pain (and a waste). And I agree with Kai that loosing the information that an email was encrypted and therefore a reply (even years after the first email) should be encrypted too, should not be lost.
So a possible approach could look like this:
(1) The secstore of the MUA (unlocked by the master passphrase at start-up) has an additional AES key (e.g. named "email-at-rest"). It is generated the first time a MUA is run.
(2) If an encrypted email is received and decrypted by the user, the session key used to decrypt the email is encrypted with the "email-at-rest" key and stored along with other message metadata.
(3) If an encrypted email is displayed, the MUA checks in the message metadata for an encrypted session key; if it is available, it used to decrypt and render the email; if not, the user is asked to decrypt the email in the usual way.
(4) Search would be able to find encrypted emails if a session key is available. AES should be fast enough to not be a burden on resources.
I think such approach has a few merrits:
(a) The email is still encrypted (in case of data leakage)
(b) No re-writing of messages/mailboxes is required
(c) Maybe this approach would even work with IMAP accounts, although a user has to decrypt messages on each individual device once.
(d) The UX implications seem minimal (actually a straight forward implementation has none)
What do you think?
Reporter | ||
Updated•2 years ago
|
I am using GPG a long time and I am a little bothered that I cannot search in the last years in my emails.
I have now a lot of emails which are not decrypted. I had in 2020 the possibility in the filter to have an action that a message could be copied as decrypted message (Enigmail), which could be updated now.
My opinion is before you implement an automatic copy on getting an email there should be first a filter function be implemented to have the chance to decrypt old messages. This filter could be also be used for incoming mails.
My suggestion would be that all PGP Mails are decrypted, HTML/TXT, OPENPGP/MIME. There should be also a Condition in the filter "Encrypted Email" and "Not encrypted Email" to ease the use which wasn't available in the old implementation. The PGP Key is now in Thunderbird and no longer in Enigmail this should ease the thing.
Is there a chance to get this function and if yes when approximately? I would very appreciate this.
Description
•