1602481 - Support sending PGP/Inline digitally signed messages, but only if they are "simple", and require opt-in with a pref

Status: REOPENED

(MailNews Core :: Security: OpenPGP, enhancement, P3)

Description

[Kai Engert [:KaiE:]]

Using attachments, or signing of HTML email, is difficult when using PGP/INLINE. Although Enigmail had code to handle that, we should require PGP/MIME for such messages.

However, we might consider to support simple PGP/INLINE messages.

For example, if a message consists only of plain text, no HTML styling, and doesn't have attachments, using PGP/INLINE is straightforward.

PGP/INLINE might still be favorable for signed announcement messages that are sent to public mailing lists. On the other hand, PGP/INLINE messages look confusing to users who aren't aware of this encoding format.

Suggestion:

• all messages that use HTML styling, or that have at least one attachments, will always be sent using PGP/MIME
• for simple messages, that Thunderbird decides to send as plain text, we'll send as PGP/MIME, by default
• have an optional pref, that the user could use to request that simple signed messages will be sent using PGP/INLINE

Potential wording:
[ ] use PGP/inline when sending a simple signed message. A message is considered simple, if it doesn't contain any text styling, no inline media, and no attachments .

Comment 1

[Magnus Melin [:mkmelin]]

Could be better to just support it as a one-off case with a checkbox to be ticked compose time. Like under Options | Delivery format | PGP/Inline

Comment 2

[Patrick Brunschwig]

I would strongly recommend to not offer any possibility for writing inline-PGP mails. See the following link why I would take the opportunity to drop an outdated feature that causes more trouble than it solves: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/

Comment 3

[Christopher Schultz]

Although I appreciate the fact that inline-PGP has a bunch of downsides (some of them security-related), the reality is that Microsoft recipients can essentially never properly receive messages which are of type multipart/signed.

I suspect there is willful resistance on the part of Microsoft to ever support it. With Enigmail (thanks several millions, Patrick, for Enigmail), it was possible to say "I know people @example.com need to get inline PGP" and messages were therefore always (and automatically) signed in this way. It was also possible to enable it on a per-message basis. After Enigmail was sunsetted, the only option available is to simply remove signatures entirely, either manually (per message) or globally (completely disable them).

If per-recipient rules could be added into tb (much like they existed in Enigmail), it would at least allow users to say "if I'm emailing someone @example.com, just disable signing" so one could continue to sign-by-default and also not have to remember to disable signing for every darned message for those specific recipients.

If inline-PGP is a no-go (which I'm actually just fine with), would a per-recipient signing-rules feature be (a) acceptable and (b) do-able?

Comment 4

[Magnus Melin [:mkmelin]]

Let's mark this wontfix.

What problems to people get with multipart/signed?

Comment 6

[git-x]

In response to comment on Bug 1759352:

What do you think is the advantage of PGP/Inline? What do you gain with it?

The main advantage is to provide an alternative to default of key attachment. For example, many organisations have implemented policies of not accepting incoming emails containing attachments. This makes PGP signature attachment-by-default useless for this particular use-case scenario. Having the PGP signature in the body of the email will pass such filtering.

Comment 7

[demiobenour]

(In reply to Magnus Melin [:mkmelin] from comment #4)

Let's mark this wontfix.

What problems to people get with multipart/signed?

For me, it is mailing lists (such as Google Groups) that add text (such as unsubscribe noticies) to every message. This breaks PGP/MIME signatures, but PGP/Inline is not affected.

Comment 8

[demiobenour]

(In reply to demiobenour from comment #7)

(In reply to Magnus Melin [:mkmelin] from comment #4)

Let's mark this wontfix.

What problems to people get with multipart/signed?

For me, it is mailing lists (such as Google Groups) that add text (such as unsubscribe noticies) to every message. This breaks PGP/MIME signatures, but PGP/Inline is not affected.

To elaborate, this is an (indirect) security problem, as it trains people to ignore bad signatures. When a huge number of signatures are bad, people will start ignoring them, which means that malicious tampering will be undetected. Preventing that is why I sign (almost) every message I send, and it requires supporting inline PGP.(In reply to Patrick Brunschwig from comment #2)

I would strongly recommend to not offer any possibility for writing inline-PGP mails. See the following link why I would take the opportunity to drop an outdated feature that causes more trouble than it solves: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/

In an ideal world I would agree with you, but in the real world PGP/Inline works in cases where PGP/MIME does not. The problems described there can be mitigated by:

1. Requiring all PGP/Inline messages to be UTF-8 encoded, and consider the message bad if the encoding is not UTF-8.
2. Consider the signature bad if there are any attachments, unless the digest of that attachment appears in the message body in some machine-verifyable format. Xen Security Advisories (https://xenbits.xen.org/xsa) might be a useful source of inspiration for how such a format could look like. Another option would be to use a custom notation subpacket containing this information.

Comment 10

[Kai Engert [:KaiE:]]

While Magnus resolved this as wontfix, I don't fully agree with wontfix.

It would be nice if Thunderbird eventually supported an optional mechanism to support inline for simple messages.

However, I don't consider it a priority right now. I consider it important to make OpenPGP in Thunderbird convenient to use, and work well.

Inline PGP is a special mode, it would require special UI to signal the user the limitations etc., it wouldn't be trivial to implement. We probably would need adjustments for subject line encryption, because there wouldn't be a good place to place that in the inner part of the inline message.

If you really know that you need PGP/INLINE, you probably know how to produce that special message with other tools, and paste it into the message composer?

Comment 11

[Kai Engert [:KaiE:]]

I'm reopening, because I have an idea how we could make this possible, in a way that doesn't require complicated UI.
I don't want to offer a toggle in the UI, because it would be complicated for that to coexist with our other UI options and choices.

Here's an idea for a possible simple approach:

We could have a hidden boolean pref something like mail.openpgp.inline.allowed set to false by default, which the user could set to true.
If false, we'd never send inline.

If true, the composer UI would automatically track the complexity of the message.
If the message is being composed in plain text mode (html disabled for the message),
and the message has no attachments,
and we're sending with encoding UTF-8,
then we could indicate in the status bar that the OpenPGP inline format will be used.

As soon as any of the above precondition changes, we'd no longer show the OpenPGP inline notice.

Comment 12

[Kai Engert [:KaiE:]]

Oh, additional precondition:

Encrypted subject must be turned off.

Comment 13

[Kai Engert [:KaiE:]]

And another precondition:

The pref being introduced in bug 1688863 should be set to "single layer".

Comment 14

[Andrei Hajdukewycz [:sancus]]

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

We could have a hidden boolean pref something like mail.openpgp.inline.allowed set to false by default, which the user could set to true.
If false, we'd never send inline.

If true, the composer UI would automatically track the complexity of the message.
If the message is being composed in plain text mode (html disabled for the message),
and the message has no attachments,
and we're sending with encoding UTF-8,
then we could indicate in the status bar that the OpenPGP inline format will be used.

As soon as any of the above precondition changes, we'd no longer show the OpenPGP inline notice.

I hadn't heard of this request before. The above seems like a lot of complex logic and conditions to enable sending plaintext-only messages. I'm not super clear on what the use cases are here? Is this really just for mail providers that don't accept attachments for some reason?

How is this not a weird niche-of-a-niche-of-a-niche?

Comment 15

[Bryan]

I can't believe Thunderbird would not implement this as part of the replacement of enigmamail.

The principal use case for inline pgp is on mailing lists. A mailing list archive will typically strip out the attachments and scrub any HTML parts. An inline signed message is unable to be edited in the archives and still have a good signature. The caveats of plain text/no attachments/8 bit encoding are typical mailing list formatting restrictions, so it's a moot point. Enigmamail tracked this fine, and at most would give a warning about non-encrypting attachments (again on a mailing list shouldn't be present)

As it stands now, when I post to a mailing list, I have to create the message in vim and copy paste it into thunderbird. This is step backwards, and frankly mutt is much better at email than the latest thunderbird in this regard.

Example of how inline works better:
https://mailman.nanog.org/pipermail/nanog/2023-September/223121.html
vs.
https://mailman.nanog.org/pipermail/nanog/2023-September/223239.html

That second one is unable to be verified correctly due to the mime parts being scrubbed/adulterated in the archive.
The inline text/plain version is easily verified.

Comment 16

[Kai Engert [:KaiE:]]

I think we could further limit this to signed messages, and don't support inline for encrypted messages.

Comment 17

[Kai Engert [:KaiE:]]

I might try to hack on this during my PTO over the holidays, no promises though.

I said above, if there any attachments, we don't use PGP/INLINE.

However, I think an exception could be made for the signing key, it could be allowed, outside of the signed contents.

Comment 18

[Kai Engert [:KaiE:]]

Attachment: WIP: Bug 1602481 - Support optional PGP/INLINE for simple messages.

Comment 19

[Kai Engert [:KaiE:]]

I've merged on top of the changes from bug 1677088

Comment 20

[Kai Engert [:KaiE:]]

The suggested patch removes some old code and complexity, and introduces pgp/inline strictly for very simple messages, and only if the user opts-in with a new pref.

Comment 21

[Kai Engert [:KaiE:]]

In phabricator, Magnus had some thoughts regarding general UI of this feature.
I'm copying the comments here, I think bugzilla is a better place for general discussions, and I think phabricator comments are better for discussing specific code.

Magnus said:
"I'm mildly stated unenthusiastic about adding support for this. I guess there's some value in supporting producing what we consume though.
If we do add it, I think it would need some UI to opt in per message. Perhaps the body context menu should have the option to add inline signature (and then lock msg for editing). @aleca - wdyt?"

In my opinion, the suggestion would require more user interface complexity than I'd be willing to invest here.
The new mode of operation doesn't seem trivial, to get right with all the various other flags that could be set.

I would like to make a simpler proposal.

I suggest that we dynamically make an additional menu item checkbox available, immediately next to the existing "Digitally sign" choice.

The menu item would be hidden in any of the following scnarios:

• if S/MIME is currently selected
• when HTML is used for composing the message,
• the user has set global (hidden) preference mail.strictly_mime

The menu item would be called "Sign using PGP/INLINE", and as the above suggests, it would be visible only when composing in plain text mode with OpenPGP selected.

The item would be disabled (grayed out), when the composer finds any condition that we don't allow:

• message has at least one attachment
• message is configured (explicitly or implicitly) to include the user's own public key as an attachment

With this approach, we wouldn't require a new pref.
The feature would always be available and discoverable in the menu.

If the user turns on PGP/INLINE, and afterwards adds an attachment, we'd silently turn it off.

Users who wish to send with PGP/INLINE will be able to double check that it is used, by opening the Security menu, and looking at the state of the checkbox (enabled and checked) prior to sending.

I prefer this approach, because we could continue to use our existing implementation, which allows full editing of the message until the user hits send, and we create the signature with the usual timing, after the user has asked to send the message.

Comment 22

[Kai Engert [:KaiE:]]

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

I suggest that we dynamically make an additional menu item checkbox available, immediately next to the existing "Digitally sign" choice.
...
The menu item would be called "Sign using PGP/INLINE", and as the above suggests, it would be visible only when composing in plain text mode with OpenPGP selected.

I'd like the new checkbox to control the signature transport format only, not enable/disable signing. I realize my above wording could be ambigious.

So in addition to "Digitally sign", a better label for the new checkbox would be "PGP/INLINE signature format"

And I forgot another condition in which we'd disable or hide it:
If "encryption" is turned on.