1777625 - Thunderbird should notify the user if a configured personal OpenPGP key is no longer usable (e.g. encryption subkey expired), and should avoid encrypting drafts with it.

Status: NEW

(MailNews Core :: Security: OpenPGP, defect, P2)

Description

[Daniel Kahn Gillmor]

Steps to reproduce:

I have an OpenPGP key that i've been using with Thunderbird for a few years, starting in my GnuPG keyring.

Its encryption-capable subkey recently expired. Before it expired i'd added a new encryption-capable subkey in GnuPG and published it.

Drafts are typically encrypted to this OpenPGP certificate. When the encryption-capable subkey expired, i could not save a draft (it was trying to encrypt to a non-encryption-capable certificate). I refreshed the cert from a pubkey file exported by GnuPG. then i could save a draft.

Actual results:

But when i tried to open a draft to review it or resume editing from it, i could not open it (presumably because librnp did not have access to the secret key, even though GnuPG does have access to it)

Expected results:

I like that drafts are saved encrypted when a key is known for my account. But they should only be saved encrypted when it's possible that i'll be able to decrypt them. otherwise, the draft can't be resumed. Why save a draft in that case?

Here are a few possible approaches seem possible when currently configured to encrypt drafts but the only encryption-capable key we have doesn't have access to the secret key that can decrypt:

• save cleartext drafts to local folder (at least they don't leak over the network, but they're not available from other devices at all)
• change the user's settings so that drafts are not encrypted (they leak over the network -- is the user made aware of this change in their security posture somehow?)
• encrypt draft messages to a new secret value stored behind the master password, unrelated to the OpenPGP certificate (this means that drafts can be seen, but can't be restored from another client that doesn't have access to this secret)
• generate a new secret subkey and attach it to the user's OpenPGP certificate (this change in the certificate needs to be communicated to other devices that have access to the draft mailbox)
• the user is asked to provide the secret subkey of the associated certificate
• thunderbird tries to extract the secret subkey from the local GnuPG installation to see whether it is available.

I don't know the right way to resolve this programmatically, but the drafts folder is definitely not usable in the current situation, so something needs to behave differently.

Comment 1

[Daniel Kahn Gillmor]

i should note: i'm running thunderbird with system librnp from debian experimental, version 1:102.0b7-1, with librnp0 also from debian experimental, version 0.17.0git20220428-1

Comment 2

[Christian Riechers]

TB103.0b2 on Linux
I cannot reproduce this with my setup, but it may be slightly different than the one described above.
librnp.so is the one shipped with Thunderbird.
Thunderbird only knows my public keys, all private keys are in the gnupg keyring.

One doesn't need to turn on encryption for a specific message, the draft will be saved encrypted as long as e2e encryption is set up for the account, and draft encryption is turned on.

That's what I did, saved a draft message, the message itself does neither have encryption nor signing turned on. The draft is saved encrypted though.

Upon re-opening the draft message via 'Edit Draft Message' from the context menu I do get the passphrase prompt for the private key, and the message is opened in it's full glory.

Comment 3

[Kai Engert [:KaiE:]]

Daniel, you are using Thunderbird's internal code (not the external gnupg pref), and you had previously imported your secret key into Thunderbird, correct?

Then you gave Thunderbird an additional public subkey, but you didn't give it the secret key - although overall this is configured as a personal key.

I agree the behavior wasn't ideal, but I also think that your scenario is very expert-special. If you decide to create a new subkey, you're in charge to also import the updated key including your new private subkey.

IMHO, THunderbird should re-check if the personal key configured for the email account is still usable. Currently, this check is only done at initial configuration time.

I think that Thunderbird needs to regularly re-check. If it detects that the configured key no longer meets TB's expectations, it should prompt the user to fix the situation. (In your scenario, it should have said it doesn't have a encryption capable key/subkey with an associated secret key, and therefore the key cannot be considered usable as a personal key)

Comment 4

[Thomas D. (:thomas8)]

Daniel, does any of the bugs from this list describe your problem?

Comment 5

[Kai Engert [:KaiE:]]

Bug 1661969 has the same underlying issue (configured key no longer usable, in particular expired).

Comment 6

[Kai Engert [:KaiE:]]

We need to decide at which times we perform the check and notification.

Maybe it's easiest to do so when composing a message with an email account that has the no-longer-usable key, and show a notification bar inside the composer window.