Note: This page describes our initial vision from October 2019. For changes since 2019, updated plans, resources and discussion venues please refer to the primary OpenPGP wiki page.

OpenPGP support in Thunderbird 78 (summer 2020 release)

Background

Two popular technologies exist that add support for end-to-end encryption and digital signatures to email. Thunderbird has been offering built-in support for S/MIME, and will continue to do so.

The Enigmail Add-on for Thunderbird has made it possible to use the external GnuPG software for OpenPGP messaging.

Thunderbird extends the Mozilla software platform that is primarily used for the Firefox browser. Enigmail requires the use of extension mechanisms, which will no longer be available in future versions of the Mozilla platform. The Thunderbird 68.x branch, which will be actively maintained until autumn 2020, will be the last versions that supports Enigmail.

As a replacement for Enigmail, the Thunderbird team intends to develop new, integrated support for OpenPGP messaging, and plans to make it available in the Thunderbird 78 release that is planned for summer 2020.

We are happy that Patrick Brunschwig, who has been developing and maintaining the Enigmail Add-on for many years, has offered to assist the Thunderbird development team.

Primary Objective

The primary objective is to be able to send encrypted email, digitally sign email, decrypt received email, verify the correctness of digitally signed email, and to provide this functionality in a secure, compatible, interoperable and user friendly way. We consider encryption and digital signatures as features that can be used either in combination or independently. When sending email, users should be able to decide on their own, which of the features they want to use, and when receiving emails, it should be possible to discover which of those protection mechanisms were used.

OpenPGP engine

Thunderbird is unable to bundle GnuPG software, because of incompatible licenses (MPL version 2.0 vs. GPL version 3+). Instead of relying on users to obtain and install external software like GnuPG or GPG4Win, we intend to identify and use an alternative, compatible library and distribute it as part of Thunderbird on all supported platforms.

As a consequence of not using GnuPG, several aspects related to OpenPGP messaging will likely work differently than in today’s Enigmail solution. We intend to identify and use another existing library that provides support for creating and processing OpenPGP messages, and we will try to reuse parts of Enigmail that aren’t specific to GnuPG. However, we’ll need to rethink several aspects, from user interface to trust models, to key management and key exchange. This text will try to outline the most relevant aspects, and offer suggestions on how Thunderbird 78 could implement them.

Key storage

To process OpenPGP messages, GnuPG stores secret keys, public keys of correspondents, and trust information for public keys in its own file format. Thunderbird 78 will not reuse the GnuPG file format, but will rather implement its own storage for keys and trust.

Users who already own secret keys from their previous use of Enigmail and GnuPG, and who wish to reuse their existing secret keys, will be required to transfer their keys to Thunderbird 78. On systems that have GnuPG installed, we might be able to offer assisted importing.

Secret keys managed by GnuPG are commonly protected with a passphrase. By using Thunderbird’s internal key storage, the Master Password feature could be reused to protect OpenPGP keys in the same way it already can be used to protect login credentials and keys used for S/MIME. This could remove the need to remember separate passwords for individual OpenPGP keys.

Key ownership verification

End-to-end encrypted messaging must protect against Monster-In-The-Middle (MITM) attacks. Behind the scenes, a key used for OpenPGP messaging consists of numbers and meta information, including information about the alleged owner. Since anyone can easily create a new random key with false meta information, it’s necessary to obtain confirmation about key ownership from the alleged owner in order to use OpenPGP securely.

Directly confirming that a key indeed belongs to the alleged owner requires an out of band communication. For example, it’s possible to calculate a short checksum for the numbers contained in an OpenPGP key. The term fingerprint is often used to describe that checksum. When meeting in person, people may exchange the fingerprints of their OpenPGP keys on paper. If the voice of the other person is known, a phone call might alternatively be used to exchange the fingerprint. Verifying that the fingerprint displayed on the computer is identical with the fingerprint obtained from the communication partner confirms the key ownership.

Once Alice has confirmed Bob’s public key is genuine, Alice should create a permanent record of having done so. The common approach is that Alice uses her own key to digitally sign Bob’s public key (including its meta information). When using Bob’s key later on, the software used by Alice will notice the signature, and can treat Bob’s key as confirmed.

Thunderbird 78 should continue to offer this mechanism. The OpenPGP library to be used by Thunderbird 78 should support digitally signing public keys. (Alternatively, Thunderbird 78 would have to remember information about successful confirmations separately.)

Key sharing

Often users of OpenPGP share their key confirmations with others, by publishing signed keys on key directories (key servers). GnuPG and Enigmail allow both uploading to, and also downloading from key servers, to obtain other people’s keys, and to learn about key confirmations that others have done.

Unfortunately we recently saw an increase of concerns about the classic OpenPGP keyserver model, because of ways in which they can be abused, and which has already caused stability and availability issues. New mechanisms for sharing keys are currently being developed by the OpenPGP community, such as Autocrypt, WKD, and a new generation of keyservers such as Hagrid. Although it’s currently unclear which mechanisms will be preferred in the future, Thunderbird 78 will likely continue to support key server interactions, in addition to the trivial mechanism to send and receive OpenPGP keys as email attachments.

On systems that have GnuPG installed, it maybe be possible to offer assisted importing for public keys of correspondents, which were previously obtained and stored using GnuPG. As part of this import, key ownership confirmations should be imported, too.

Often, key ownership confirmation through direct human interaction is considered impractical. An alternative is indirect verification. Bob might have signed David’s key. But does Alice trust Bob to confirm key ownership of other people? GnuPG software allows Alice to decide and configure if she considers Bob trustworthy for confirming the key ownership of other people. GnuPG software implements rules, which can allow a number of uncertain, indirect confirmations to be considered equivalent to a direct key confirmation. By combining Alice’s own confirmations with the information found in other keys, usually retrieved from keyservers, GnuPG could automatically treat David’s key as confirmed. This mechanism and the set of all confirmations found on keys is commonly described as the Web of Trust.

It’s currently undecided if Thunderbird 78 will be able to reuse the trust configurations made using Enigmail and GnuPG software. It’s also still unclear if Thunderbird 78 will implement the Web of Trust model for indirect confirmations.

To summarize the previous paragraphs, Thunderbird 78 will likely require a direct ownership verification in order to treat an OpenPGP message using that key as fully secure. It’s undecided if an equivalent for indirect confirmation, such as by using the Web Of Trust, will also allow keys to be treated as fully secure.

No opportunistic encryption

Thunderbird 78 will allow to use either confirmed or unconfirmed keys for OpenPGP messaging. However, the user interface will clearly distinguish the more secure use of confirmed keys from the less secure use of unconfirmed keys. For users who prefer to avoid unencrypted email completely, we might offer an advanced configuration, that could require all outgoing email to be encrypted, either using any available key, or by requiring the use of confirmed keys, only.

It’s a controversial question whether email software should automatically use opportunistic encryption, or whether the user should be required to actively opt in, prior to using end-to-end email encryption. Should emails be automatically encrypted, whenever possible, without asking the user? Should email software automatically create OpenPGP private keys, distribute them, thereby enabling the automatic use of encryption?

It’s unrealistic to hope to implement an automatic solution that works for all emails, given the wide variety of different email client software. Although Thunderbird is a popular email client, it seems realistic to assume that a large portion of the emails that Thunderbird users send and receive are with correspondents that don’t use Thunderbird. Consequently, even if Thunderbird supported an automatic solution, a large portion of email would not be covered by it.

With a fully automatic solution, there’s the potential risk that a Monster-in-the-Middle could trick Alice into using the Monster’s OpenPGP key when intending to encrypt email to Bob, without Alice noticing.

The Trust On First Use (TOFU) concept attempts to minimize the risk, but there’s still the risk that the first use already involves a false key. And TOFU cannot completely avoid all interactions with the user. It’s a common scenario that users lose their keys, start to use a different computer, or they might use more than one computer with different keys. TOFU cannot automatically handle these scenarios in a secure way. It’s necessary to assist the user in resolving key conflict situations interactively, for example by recommending an out of band communication to confirm the correspondent’s correct key.

Furthermore, starting to use OpenPGP comes with some responsibility for the future. Once a user distributes their own key to others, they’ve opened Pandora’s box. Others might discover the keys later and send encrypted email at any time in the future. If the key has been lost, either because the computer broke and no backups of they are available, or because the user forgot the passphrase that was used to protect the key, the incoming encrypted email cannot be read. Also, if the key has been lost, the archive of encrypted email that’s still available on your mail server can no longer be read either.

For the initial version of Thunderbird with OpenPGP support, Thunderbird 78, we’ll not yet enable OpenPGP encryption for emails automatically. Instead, we’ll require that users opt in, prior to using it. However, it should be easy to opt in, and we might implement a smart user interface, that allows the user to discover the the availability of the OpenPGP messaging features, and offer interactive assistance that makes it easy to get started. How exactly this will be done, needs to be worked out during the next year, while we develop Thunderbird 78.

For users of Thunderbird 78 who had previously installed Enigmail and had opted in to use OpenPGP, we will attempt to migrate their preferences related to the use of OpenPGP.

Frequently Asked Questions (FAQ)

Will OpenPGP cards be supported for private key storage ?

Update: How to use OpenPGP smartcards with Thunderbird 78.

Probably not, because we don't use the GnuPG software that's usually required to access OpenPGP smartcards. However, we'll investigate potential options.

Thunderbird:OpenPGP