1634496 - Show additional details about signature and recipient keys of an OpenPGP message

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Kai Engert (:KaiE:)]

Currently, when we cannot decrypt an OpenPGP message (the secret key isn't available), we show a "bad encryption" status icon, and the message pane remains empty.

Should we show an error message in the message pane?

Comment 1

[Jon]

Information about what keys the message can be decrypted by (in a way that can be selected and copied out) is very useful in debugging problems here, wherever that goes (the current "Enigmail Security Info" dialog box is decent).

I find the "blank" email message pane confusing (also what happens if a message is still loading). Something to distinguish messages which are loaded but have some other problem would clarify. Possibly greyed out, with an error message and next-steps options linked (what keys was it encrypted for, view source , etc.) to visually show the user that yes, the message "loaded" but could not be displayed, and some paths to figure out what went wrong?

Comment 2

[Kai Engert (:KaiE:)]

At least I've added a notification bar if we cannot decrypt as part of bug 1649030 comment 2.

Let's morph this bug into the remaining TODOs.

Comment 3

[Kai Engert (:KaiE:)]

If we cannot decrypt a message, show information about the recipient keys.

Maybe this information (full list of recipient keys) should always be accessible in the security details.

Comment 4

[Kai Engert (:KaiE:)]

I have a patch that enhances the "message security info" dialog for OpenPGP messages.

If a key ID is known to be a subkey, it will show both primary and sub key IDs.

The list of all recipient keys of an encrypted message will be shown.

I'll attach some screenshots FYI.
(The last screenshot is using smartcard decryption using external GPGME, so we cannot be sure which key ID was our own decryption key ID.)

Comment 5

[Kai Engert (:KaiE:)]

Attachment: Bug 1634496 - Show additional details about signature and recipient keys of an OpenPGP message. r=PatrickBrunschwig

Comment 6

[Kai Engert (:KaiE:)]

Attachment: info-keyid-1.png

Comment 7

[Kai Engert (:KaiE:)]

Attachment: info-keyid-2.png

Comment 8

[Kai Engert (:KaiE:)]

Attachment: info-keyid-3.png

Comment 9

[Kai Engert (:KaiE:)]

Attachment: info-keyid-4.png

Comment 10

[Kai Engert (:KaiE:)]

Attachment: info-keyid-5.png

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b4e7af5163d6
Show additional details about signature and recipient keys of an OpenPGP message. r=PatrickBrunschwig

Comment 12

[Kai Engert (:KaiE:)]

Comment on attachment 9165041 [details]
Bug 1634496 - Show additional details about signature and recipient keys of an OpenPGP message. r=PatrickBrunschwig

Important additional OpenPGP message details shown in the message security info window, that will help users with diagnostics and awareness.

Comment 13

[Arvidt]

Generally, am I correct, that for encrypted messages, where the encrypted text is not signed, the statement "This message was encrypted before it was sent" is not correct?
You never know who encrypted? Even a signed message could have been sent in clear text and only afterwards been encrypted on the transport by a third party?

I think the explanation of case "encrypted but unsigned" is not quite correct as shown in the screenshot in comment 8.

Am I right with the following:

a) an encrypted message can't be modified (it can' be read, so it can't be modified, modifying the encrypted text would lead to invalid/undecryptable message)
b) if a) is true, modification of a message can only happen if the sender has sent unencrypted and someone later modified the clear text message and then encrypted the message

So, for the case "encrypted but unsigned" I would suggest the following explanation change (the text is especially for this case only):

No Digital Signature: The first two statements are correct. Suggestion to enhance the third sentence:
No Digital Signature
It is also possible that the message was sent unencrypted, has been altered and afterwards been encrypted while in transit over the network.

Message is Encrypted
This message was encrypted, but it is not known, if the sender of the message encrypted it, or the message was sent unencrypted and was encrypted by someone else later, while on transport. The absence of a digital signature means, that it could be that the original unencrypted message was also modified before encryption. Once a message is encrypted, it can not be modified anymore.

I heard of this nice thing:
Sign the message, encrypt the signed message, and then sign the encrypted signed message. Only in that case, I think, it is guaranteed, that the signer(originator of the text) also encrypted.

This whole stuff is complicated, and I understand that the users should not be overburdened with paranoid details. But also, I think statements made should be 100% correct (at least based on the assumption that no private key has been stolen or given away (e.g. to anti spam service providers) or other compromise of the end-computers).

Comment 14

[Magnus Melin [:mkmelin]]

(In reply to bugzilla0248 from comment #13)

Generally, am I correct, that for encrypted messages, where the encrypted text is not signed, the statement "This message was encrypted before it was sent" is not correct?

No, the statement is correct. It's encrypted before it's sent, from somewhere, by someone. It's not know who sent it encrypted. It's not known if it's the original message the claimed sender sent.

You never know who encrypted?

Correct, that's why encrypted only doesn't give much advantage except for in very special cases.

Comment 15

[Arvidt]

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

No, the statement is correct. It's encrypted before it's sent, from somewhere, by someone

OK, I interpreted "was sent" as of "Author clicked on the send button". Then I would suggest to say "This message was encrypted, but it is unknown by whom."

You never know who encrypted?

Correct, that's why encrypted only doesn't give much advantage except for in very special cases.

Hm, I quite don't get it. I think of two cases:
a) author of message sends encrypted and unsigned
b) author of message sends clear text and unsigned, and MITM encrypts (possibly modifies message, too)

a) Full e2ee baseline security (confidential & integer), great advantage compared to clear text mail. No disadvantage compared to clear text mail.

b) Since original clear text mail has zero security, there can not be any loss of security. There is a small benefit, that after MITM encrypted, message is secure(confidential+integer). No disadvantage compared to clear text mail.

I think, currently case b) is a very special hypothetic case. Or do already currently exist e.g. Mail providers (or companies "mail security gateways" that collect public keys, and as a service encrypt mails on the transport that they received unencrypted? What could be the motivation to do this for others? I cannot imagine. If they have a clear text mail, why not be happy with it, why make confusion when sender get's known that the clear text mail was encrypted on it's way?

If a) should be the common case, shouldn't that be a great advantage? What do I miss here?

Could it be, that encryption only has a big advantage in the average uncritical case, but one can not rely 100% on it, and that You mean, if not 100% reliable then this is 0% advantage, because You are focussed on critical-security usage ?

Comment 16

[Arvidt]

To not spam this bug, I will post on Topicbox.

Comment 17

[Magnus Melin [:mkmelin]]

Cases #a and #b can't be distinguished, that's why it adds basically no benefit to use encrypted only. But, you could use encrypted-only for cases say, you're a whistle-blower but don't want things to be able to be verifiably tracked back to you.

The case of a service provider encrypting is probably super rare.

Encryption-only gives you privacy for the one message. We just must be sure we don't trick the user to thinking it's secure, and act (e.g. transfer money or reply) on that "secure" assumption, with potentially sensitive information

Comment 18

[Wayne Mery (:wsmwk)]

Comment on attachment 9165041 [details]
Bug 1634496 - Show additional details about signature and recipient keys of an OpenPGP message. r=PatrickBrunschwig

Approved for beta
Approved for esr78

Comment 19

[Kai Engert (:KaiE:)]

https://hg.mozilla.org/releases/comm-esr78/rev/f508d0002996430090b7e7cb25c2ea11f5df2997
https://hg.mozilla.org/releases/comm-beta/rev/07fd8331e66639ab2ce0090c0230da3eaf9bc0ad