Sign messages by default, but don't attach digital signature file
Categories
(MailNews Core :: Security: OpenPGP, enhancement, P2)
Tracking
(Not tracked)
People
(Reporter: chris, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0
Steps to reproduce:
Thunderbird 77.0b3
- For Account A, check configuration 'Add my digital signature by default'
- Verify setting #1 saved
- Compose new message from Account A
Actual results:
Observe in message Security menu that both 'Digitally sign this message' and 'Attach my public key' are checked
Expected results:
I want configuration settings that allow the default compose behavior to be:
'Digitally sign this message' = checked
'Attach my public key' = not checked
I do not want to create "attachment noise" for all my recipients. Almost always I want to sign by messages (similar desire in #230420), but not attach the public key file.
I searched about:config and was unable to find a setting to separate signing from attachment.
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
See also bug1647182 regarding sending the public key in the mail header.
Comment 2•4 years ago
|
||
aside: I'd like a refinement, whereby we don't send the pubkey to people with whom we've already got a PGP relationship. e.g. we have their key. Otherwise I keep spamming regular contacts with my key, which is wasteful.
Or perhaps only send a key once to any recipient? That probably doesn't scale.
apols if this is off-topic.
Updated•4 years ago
|
Is this related/would be handled by bug 1629309?
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to pbrandao from comment #3)
Is this related/would be handled by bug 1629309?
This bug is related, but not be resolved with an enhancement that directly addresses bug 1629309.
These suggestions, along with comment #2 from Calum Mackay, all relate to the idea of not spamming people with key data.
(In reply to Chris Horn from comment #4)
(In reply to pbrandao from comment #3)
Is this related/would be handled by bug 1629309?
This bug is related, but not be resolved with an enhancement that directly addresses bug 1629309.
These suggestions, along with comment #2 from Calum Mackay, all relate to the idea of not spamming people with key data.
Agreed, my point is that from the point of view of the UI and even functional implementation wise, they could be addressed together.
Totally relate to:
spamming people with key data.
Comment 6•4 years ago
|
||
An OpenPGP signed message will be shown with a signature file attachment by clients that don't support OpenPGP.
A recipient that uses a client that supports OpenPGP requires the public key to verify the signature. In other words, verification is impossible without having the public key available.
That's the reason why it makes sense to send the public key by default.
We tag the attached key with content type application/pgp-keys. This means, an application that supports OpenPGP could decide to similarly hide the key attachment, if the key is already available, or alternatively it could show a dedicated button to access the attached key, keeping it separate from other attachments. Thunderbird will probably do so in a future version.
Reporter | ||
Comment 7•4 years ago
|
||
This rationale is only valid in an alternate universe where all email clients offer better OpenPGP support. Until that time (which is unlikely to ever exist), Thunderbird's default behavior is to spam all recipients with key data and minimize the value of email attachment indicators.
Comment 8•4 years ago
|
||
It's not spamming. It serves a purpose. If you send a signed email to someone who doesn't use OpenPGP compatible software, you could equally argue that you're spamming them with a signature file attachment, every time you send them a signed message.
Comment 9•4 years ago
|
||
To be clear, I don't oppose the requested enhancement (introduce a preference, that can be used to disable attaching public keys automatically to signed messages). We can consider to offer that in a future version of Thunderbird.
But I'd like to keep the current standard configuration, as it improves the usability of signed messages.
Reporter | ||
Comment 10•4 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #8)
you could equally argue that you're spamming them with a signature file attachment
Valid.
Comment 11•4 years ago
|
||
I think this ticket should be considered.
If a person needs our signature, it should be downloadable from a key server just like it happened with Enigmail.
Comment 12•4 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #6)
An OpenPGP signed message will be shown with a signature file attachment by clients that don't support OpenPGP.
A recipient that uses a client that supports OpenPGP requires the public key to verify the signature. In other words, verification is impossible without having the public key available.
That's the reason why it makes sense to send the public key by default.
We have the classical chicken and egg problem here:
- You can only trust the attached key, if you trust the E-Mail in the first place. Thus there is no need for the digital signature.
- If you don’t trust the E-Mail, then you cannot trust the attached key either.
Sending keys by default, i.e., unsolicited, will have the result that people will blindly accept any new keys that are being sent to them, because it happens all the time and usually everything should be okay. What worries me is the following: a lot of people simply do not understand the possibility of man-in-the-middle attacks and will simply accept every (forged) E-Mail with a key attached to it. This would allow an attacker to easily replace a valid key of a target with his own.
I would like to compare the situation to what happens when using Firefox to browse to a website with a self-signed certificate. You get a big, fat warning, and that is a good thing. In Thunderbird, on the other hand, the only thing that happens when you get an E-Mail signed by such a key is that a small tick mark is replaced with a small question mark next to the OpenPGP symbol.
Comment 13•4 years ago
|
||
Sorry but that's an incorrect comparison. You shouldn't trust the attached key because you trust the mail in the first place. You get the key in the mail, then you can choose to trust it if you want, or preferably, verify the fingerprint through other channels (phone, pic over whatsapp or in person etc.). But, you can not verify/trust a key you do not have, that's the reason it's attached in the first place. IF it ever changes, you'll get warned.
Comment 14•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #13)
IF it ever changes, you'll get warned.
Hm…fair point.
I would still like the option to change that default behaviour (comment #9) to avoid the redundancy of repeatedly sending your key to people who already have it (comment #2).
Comment 15•4 years ago
|
||
I support the proposal to include a configuration option to not attach the public key per default. All of my e-mails are signed and my public key file is rather large. Attaching it to every e-mail means that every e-mail is at least some hundred kilobytes large, which is definitively not desired.
I understand the reasoning to easily allow even non-technical people to obtain the corresponding public key for a digital signature, but at the moment, I have to either manually uncheck the "Attach My Public Key" option for every single e-mail (!) or I have to disable the automatic digital signature generation as a default.
Comment 16•4 years ago
|
||
One more thing to consider: the attach-option currently switches two things:
- the addition of an attachment "OpenPGP_0x....asc", as discussed above
- the addition of an
Autocrypt: addr=...; keydata=...
header
While adding the attachment every time by default is often undesired (see above comments and I also don't want that), the header may be another thing. It gets ignored by MUAs that can't handle it, it does not confuse recipients, it is even a bit shorter than the attachment so arguably an acceptable overhead.
My personal preference would be to split the two things up:
- add a per-account config option for the default of the attach-option in the composer
- have that attach-option only affect the visible attachment, not the header
- add another per-account config option to "use Autocrypt header" without adding a similar option in the composer
- then the Autocrypt header is added if that option is on and if the public key of a recipient is unknown. Disadvantage: if we change our public key, the recipient would not be informed automatically
Comment 17•4 years ago
|
||
Is there any workaround or (dirty) trick to never attach the signature?
I'm using web key directory anyway, so there is no reason for me to ever attach it.
And having to disable it with every single email I send is just to cumbersome.
Thanks for any suggestion for a workaround or trick!
Reporter | ||
Comment 18•4 years ago
|
||
(In reply to Martin from comment #17)
Is there any workaround or (dirty) trick to never attach the signature?
I resorted to just disabling message signing entirely.
Comment 19•4 years ago
|
||
In my opinion this is a duplicate of bug 1654950, which is resolved with 78.5.0 by introducing a new config option mail.identity.default.attachPgpKey
, which can be set to false.
Comment 20•4 years ago
|
||
Thanks Nicolas, agreed.
Description
•