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

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, defect)

Description

[Justus Winter]

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.

Comment 1

[Kai Engert [:KaiE:]]

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.

Comment 2

[demiobenour]

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

Comment 3

[Justus Winter]

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

Comment 4

[Kai Engert [:KaiE:]]

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.

Comment 5

[Justus Winter]

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

Comment 6

[Kai Engert [:KaiE:]]

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

Comment 7

[Justus Winter]

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.

Comment 8

[Kai Engert [:KaiE:]]

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.

Comment 9

[Justus Winter]

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.

Comment 10

[Nickolay Olshevsky]

(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.

Comment 11

[Ronald Tse]

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

Comment 12

[Nickolay Olshevsky]

JFYI: this functionality landed RNP's master via the https://github.com/rnpgp/rnp/pull/1807
Update: this functionality is available as part of v0.16.2 release.

Comment 13

[Kai Engert [:KaiE:]]

Thanks Nickolay. We've updated Thunderbird to v0.16.2 in bug 1790116 in October 2022.

Our code already had the ability to use the combined method, when using RNP exclusively.

I have a patch that also implements the combined method when using external GnuPG for signing, and producing a message that's both signed and encrypted.

The patch uses a new pref, to enable or disable the use of separate MIME layers.

We might want to land the pref initially set to the classic (separate) behavior, to check if there are any regressions being noticed.

However, I think we should quickly afterwards change the pref to use the combined method by default.

Comment 14

[Kai Engert [:KaiE:]]

Attachment: Bug 1688863 - Implement signing and encryption in a single OpenPGP MIME layer for external GnuPG. r=mkmelin

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/abb2293802ec
Implement signing and encryption in a single OpenPGP MIME layer for external GnuPG. r=mkmelin

Comment 16

[Kai Engert [:KaiE:]]

Tests of existing behavior still work as is, no unexpected side effects revealed.

I suggest we finish this work by enabling the new method by default.

Comment 17

[Kai Engert [:KaiE:]]

Attachment: Bug 1688863 - Use combined signing and encryption encoding for OpenPGP messages by default. r=mkmelin

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b5d4026df31b
Use combined signing and encryption encoding for OpenPGP messages by default. r=mkmelin