Open Bug 1688863 Opened 2 years ago Updated 5 months ago

When encrypting mails using OpenPGP, please use the 'combined method'

Categories

(MailNews Core :: Security: OpenPGP, defect)

defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: justus, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Send an email encrypted using OpenPGP.

Actual results:

Resulting mail used 'RFC 1847 Encapsulation' (see https://tools.ietf.org/html/rfc3156#section-6.1).

Expected results:

Resulting mail uses the 'combined method' (see https://tools.ietf.org/html/rfc3156#section-6.2).

This is the preferred method of constructing mails encrypted with OpenPGP. It has several advantages:

  1. It fixes a security problem called surreptitious forwarding (see https://theworld.com/~dtd/sign_encrypt/sign_encrypt7.html) in combinationo with the proposed 'intended recipient subpacket' (see https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-10#section-5.2.3.29).
  2. It is more robust, because the signature is computed over the content of the literal data packet contained in the OpenPGP message, where as with the encapsulation method it is computed over the content of the mime node, subject to mime parsing.
  3. It is much simpler to generate and consume.
Component: Untriaged → Security: OpenPGP
Product: Thunderbird → MailNews Core

Thunderbird 78 supports the combined use of internal RNP and external GnuPG.

Expert users may configure a secret key managed by GnuPG.

If this is done, all signing operations will be routed through GnuPG. However, because Thunderbird always uses its internal mechanisms for public key management, we always use the internal RNP library to encrypt.

This means that we must technically be able to use a two phase approach to create signed and encrypted messages. The nesting was the obvious approach to do that.

We currently always use the two step approach, even when doing both operations using RNP, for consistency.

Is it technically possible to use the combined method with external GnuPG?

Flags: needinfo?(justus)

Is it technically possible to use the combined method with external GnuPG?

Of course! I'll focus on the consumption side, because the production side is trivial.

There are two ways to use GnuPG for the decryption. The dirty way is to use gpg --unwrap to decrypt, then your other OpenPGP implementation to verify the signed message. The proper way is to do all operations (both decryption and verification) in your OpenPGP implementation, and talk to the gpg-agent to decrypt the PKESK. That is what we do in the Octopus, see https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/blob/main/src/op_verify.rs#L852

Flags: needinfo?(justus)

Thunderbird already supports the combined method when consuming.

The production part is the part that would have to be solved with the Thunderbird requirements.

Because RNP is used exclusively for all public key operations, even when using GnuPG for secret key operations, it would be necessary to have RNP code that can take a signed message (from GPGME), and convert it into a combined signed and encrypted message.

The production part is the part that would have to be solved with the Thunderbird requirements.

Because RNP is used exclusively for all public key operations, even when using GnuPG for secret key operations, it would be necessary to have RNP code that can take a signed message (from GPGME), and convert it into a combined signed and encrypted message.

That is one way of doing it (and it is possible to do that using Sequoia), but this is the dirty way, the converse of GnuPG's gpg --unwrap.

The better way is to talk to gpg-agent for the secret-key operation. That is what we do in the Octopus, see https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/blob/main/src/op_sign.rs#L153

As a side note, if you use the Octopus today, it will make Thunderbird emit mails using the 'combined method': https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/tree/main/#protection-from-surreptitious-forwarding

In comment 5 I don't see an answer to the challenge presented in comment 4.

In comment 5 I don't see an answer to the challenge presented in comment 4.

I don't understand that statement. Are we challenging each other now? To what? A duel?

I originally raised the issue. You said it couldn't be done. Demi asked if it was possible at all. I replied it is not only possible, but there are two ways to do it. And I know it is possible to do because we did it.

You don't want to do it? That is fine with me.

Justus, it seems you are offended, but I don't understand why you are offended.

Maybe my use of the word "challenge" wasn't clear?
I'm using "challenge" in the sense of "here we have a problem that is difficult to solve".

With "challenge presented in comment 4" I intended to say, this is what we need to solve, and it's not yet clear how we can solve it. [edited sentence to clarify]

In comment 6, I intended to say, comment 5 doesn't yet help me to understand how to solve it using a combination of GnuPG and RNP.

This bug has been filed against Thunderbird, that means, the purpose of this bug is to find a solution that can be implemented based on the technologies that Thunderbird uses.

I'll appreciate constructive suggestions for how to solve it. If we can find a way to solve it, then we could consider to implement it and switch Thunderbird to use the combined approach.

To reiterate, when using the external GnuPG configuration, we must create the signature using GnuPG, and we want to create the encryption using RNP. This is because currently Thunderbird doesn't want to use GnuPG for public key operations like encryption, because it wants to manually handle the decision which public keys are acceptable, and doesn't do management of public keys in the GnuPG database.

We already have a solution for the secret key operation (GPGME). Suggesting a different approach for performing the secret key operation (you suggested to use gpg-agent) doesn't seem to help reaching the goal of this bug.

What we'd need is a mechanism inside the RNP library. That's my understanding. We'd need an API inside the RNP library to say: Take this signed OpenPGP message, and transform it into a signed+encrypted message, encrypted to the following set of public keys available in the RNP keyring.

Justus, it seems you are offended, but I don't understand why you are offended.

I am, in fact. If I didn't answer your question, then it likely means that I didn't understand the question. Therefore, making progress requires restating the question in a way that helps me understand the problem.

On the other hand, your comment did not help with making progress, and it was stated in a way that seems passive-aggressive to me.

In contrast, you now restated the problem, and we are able to make progress.

This bug has been filed against Thunderbird, that means, the purpose of this bug is to find a solution that can be implemented based on the technologies that Thunderbird uses.

Maybe the techniques I outlined can be implemented in RNP. If that is impossible, you could consider using different technologies. If neither is possible, then it indeed seems impossible to implement this in Thunderbird, although that seems to be an unfortunate outcome given that it is clearly possible to implement as demonstrated by the fact that we did it.

(In reply to Kai Engert (:KaiE:) from comment #4)

The production part is the part that would have to be solved with the Thunderbird requirements.

Because RNP is used exclusively for all public key operations, even when using GnuPG for secret key operations, it would be necessary to have RNP code that can take a signed message (from GPGME), and convert it into a combined signed and encrypted message.

@Kai: I created an issue here: https://github.com/rnpgp/rnp/issues/1795
Feel free to drop a comment whether this should be prioritized.

@Kai we are happy to prioritise this functionality for Thunderbird, and will update this ticket once it is completed.

JFYI: this functionality landed RNP's master via the https://github.com/rnpgp/rnp/pull/1807

You need to log in before you can comment on or make changes to this bug.