Closed Bug 1670767 Opened 4 years ago Closed 4 years ago

Attach public key flag is bogus

Categories

(MailNews Core :: Security: OpenPGP, defect)

Product:
MailNews Core
Component:
Security: OpenPGP
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1654950

People

(Reporter: nuesken, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

Mail account with PGP (and maybe also S/MIME) support.
Signing turned on by default.

Actual results:

Public key is attached by default.

Expected results:

Public key is NOT attached by default.
Public key must be attached only if I choose to attach it. (Usually on first contact or on request.)

This is a severe security issue.
This way of handling the "ATTACH PUBLIC KEY" feature leads people to TURN OFF signing entirely.

Worse: turning off default signing and then enabling it for a certain message toggles "ATTACH PUBLIC KEY"
even though that menu entry is not touched by the user.

This bug is connected to Bug 1654950, and maybe a consequence of a decision with Bug 1628097.

Whether "ATTACH PUBLIC KEY" should default to ON or OFF should be a user issue.
Without configuration it should be OFF, as it is needed only for 1 out of 100 messages.

Component: Security → Security: OpenPGP
Product: Thunderbird → MailNews Core
Flags: needinfo?(mkmelin+mozilla)
See Also: → 1654950

Duplicate of bug 1654950.
Though I don't agree. If you don't attach the key, chances that the recipient can do anything reasonable with the signing are limited so the result you get is more "feel good" for signing rather than filling a real purpose. It's the same if you signed earlier - they might not have imported the key at that time. (Yes, keyservers, well we don't support uploading atm, and there's many problems in that area as well.)

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → DUPLICATE

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

Duplicate of bug 1654950.
Though I don't agree. If you don't attach the key, chances that the recipient can do anything reasonable with the signing are limited so the result you get is more "feel good" for signing rather than filling a real purpose. It's the same if you signed earlier - they might not have imported the key at that time. (Yes, keyservers, well we don't support uploading atm, and there's many problems in that area as well.)

*** This bug has been marked as a duplicate of bug 1654950 ***

I don't agree that this is entirely a duplicate. The issue presented above is that, if the user manually toggles to enable signing while composing a message, it also toggles attaching the key. There is no visual indication that an attachment is being added to the message unless the user pulls the security menu down again.

bug 1654950 is regarding the inability to disable key attachment by default while enabling signing by default.

I don't see the benefit to attaching the key to every email. Aside from the obvious issues with having an attachment on every message, attaching both the key and the signature to the same message doesn't prove anything about the authenticity or integrity of the message. For security purposes, the key should not only not be in the same message, but ideally not transmitted via the same communication channel. Attaching the key to the message only shows that the message hasn't been altered since it was signed with that particular key. It proves nothing about who attached the key and signed it or whether it might have been altered beforehand or spoofed entirely, unless the user already has a copy of the key to check against.

Attaching the key is the way to get a copy in the first place. After that you need to use other channels to verify it's the right key (right owner). But it's pretty clear obtaining the key through email is perfectly fine - what trust you want to have in it is unrelated.

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

Attaching the key is the way to get a copy in the first place. After that you need to use other channels to verify it's the right key (right owner).

But it's pretty clear obtaining the key through email is perfectly fine - what trust you want to have in it is unrelated.

These two statements are contradictory.

So you agree then that the key attached to the email must be verified by some outside means. Then there is no point to sending the key that way to begin with, much less to each and every single message, and the trust I have in it is most certainly not unrelated.

The point is that the present choice forces me to send my public key EVERY TIME unless I think of disabling it EVERY TIME.

And if signing by default is disabled but I turn it on for a given message
then I am forced to send my public key THIS TIME unless I think of disabling it THIS TIME.

Both situations are undesirable. The standard case is that I sign my mails (all but those where I choose not to or where I know the recipient has a problem with it). And the standard case is that I transmit my key either by choice or via the central repositories.

"If you don't attach the key, chances that the recipient can do anything reasonable with the signing are limited so the result you get is more "feel good" for signing rather than filling a real purpose." is wrong in my eyes. You sign a paper contract with your handwritten signature, right? Most of the time the other side is unable to verify the signature. Because this verification only becomes important in case of problems. And that is still early enough for asking an expert in handwritings for a check. Same here: sending the key afterwards often is early enough.

The least is that the user can choose whether she wants such an automatic public key transfer or not.

Baseline: We want that people use signing and encryption for their emails.

To that end enigmail has developped some good procedures for dealing with key-attachments and recipient dependent things. Procedures like asking the user whether signature/encryption settings are ok before executing an unintended ATTACHPUBLICKEY. These should be carried over to tb78.

(In reply to Karl from comment #5)

These two statements are contradictory.

No, without having a copy to verify, you can't do anything. It's the key verification that should happen in another channel.

PS: Bug 1654950 is 3 month old and its priority is still not set. In my eyes this is so severe that it almost disables tb78 for secure settings.

PPS: Have you noticed that an email with an attached key gets marked as one with an attachment? This is logical but makes this attachment marker much less useful because people usually look for mails with attachments meaningful to them. Contrasting, the forcedly attached public key is at best meaningful for the signature verification.

The discussion about the kind of verification of signature and public key is unrelated to my point.
I should not be forced to send my public key with every signature unless I explicitly turn it off EVERY TIME.

(In reply to Michael Nüsken from comment #6)
Comparing to hand signature is not really useful - you can't usually verify that much either way.
Quite frankly, I think signing (only) is of very little use - though there are some. The actual beef it that by getting the key you're able to encrypt.

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

Attaching the key is the way to get a copy in the first place.
Disagree.
There are keyservers. My keys are there. If need be a pointer to this fact would be enough.

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

(In reply to Michael Nüsken from comment #6)
Comparing to hand signature is not really useful - you can't usually verify that much either way.
Quite frankly, I think signing (only) is of very little use - though there are some. The actual beef it that by getting the key you're able to encrypt.

Well, signing does two things: (1) It prevents modifications. (2) It links the content with the sender.
Encryption does NOT prevent modifications.

(In reply to Michael Nüsken from comment #9)

The discussion about the kind of verification of signature and public key is unrelated to my point.
I should not be forced to send my public key with every signature unless I explicitly turn it off EVERY TIME.

Agreed, and I don't understand the resistance to the user having more flexibility from the program.

My point was that attaching the key to the email is not a good practice to begin with, something I would avoid doing where possible even when I did need to transmit the key. I'm the type who will send someone a username and password by two separate channels (such as reading one verbally and sending the other via SMS). It strikes me as relatively useless for a user to receive a signed email and the key to verify it received not only by email, but in the very same message? That doesn't prove anything other than it wasn't modified after an unknown person signed with an unverified key, potentially after the message was sent. You would still have to verify that key either by receiving it or its fingerprint through another channel. So attaching it to the email is fairly useless in the first place. I certainly would not want it on every message...

(In reply to Michael Nüsken from comment #12)

Well, signing does two things: (1) It prevents modifications. (2) It links the content with the sender.
Encryption does NOT prevent modifications.

The use cases in practice are very few where preventing modifications (where not encrypted) would matter.
We had some discussion around this earlier - and no such cases really surfaced except software release mailing lists (checksums).

(In reply to Karl from comment #13)
Since you should verify over another channel, it doesn't really matter that which channel you got the key from originally. What matters is you got it, so that you can verify it.

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

(In reply to Karl from comment #13)
Since you should verify over another channel, it doesn't really matter that which channel you got the key from originally. What matters is you got it, so that you can verify it.

Which is not the point at all. You should receive the key through a trusted channel to verify the signature. Now because the key is in the same email as the signature to be verified, you have to verify the key too. Do you imagine this will take place with each and every email over the course of years that the sender uses this key? Not likely.

I'm sorry but that is not a valid argument against the user having the option to not attach the key automatically to every message. The very fact you suggest the key then needs to be verified externally shows that it's useless to have it attached repeatedly. What should happen is the user should acquire the key from a more trusted comm channel than email (i.e. floppy disk) or from a public keyserver, and retain that key indefinitely so that it does not need to be attached to the email at all to verify the signature. Sending the key to a recipient via email would only be an occasional thing, if done at all.

Having the key attached automatically to every message causes numerous problems, which have already been discussed, and is completely unnecessary.

If you think the preferred way to get encryption working is by passing keys on floppy disks, it doesn't seem you've thought this through... Like I said, only the key verification needs a different channel (to be secure).

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

If you think the preferred way to get encryption working is by passing keys on floppy disks, it doesn't seem you've thought this through... Like I said, only the key verification needs a different channel (to be secure).

That was a joke, and there's no need for you to be defensive or rude, but it was also true -- passing keys by hand on portable media would be one example of a more suitable method for transmitting the key than attaching it to the very same email it's supposed to authenticate. The point being, which I have also made abundantly clear, that attaching the key to every single email by default with no option to change it without disabling the whole system is not appropriate, useful, or free of peripheral problems.

The user should have the option to configure it in the way that best suits their usage. If you believe the user should not have that choice, by all means, make that case.

There is already bug 1654950 for an option.
All I'm saying is the reason you seem to want that option doesn't make sense - it's just now how OpenPGP works. You have to give trust to the key for the key to do anything, and you can't give trust (verify) to something you don't have.

bug 1654950 is about a separate issue. That bug is for the missing option of automatically signing emails but not automatically attaching the key. That bug occurs under Account Settings > End-To-End Encryption.

This bug 1670767 was opened for an issue wherein clicking the security button in the compose window and then clicking the option to sign the message also erroneously enables the option to attach the key, which must then be toggled again to off if desired. This bug occurs in the message composition window.

The bugs are not actually duplicates.

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