Ability to mark key pairs as "accepted personal keys" or not
Categories
(MailNews Core :: Security: OpenPGP, enhancement, P1)
Tracking
(thunderbird78 fixed)
Tracking | Status | |
---|---|---|
thunderbird78 | --- | fixed |
People
(Reporter: KaiE, Assigned: KaiE)
References
(Blocks 1 open bug)
Details
Attachments
(3 files, 5 obsolete files)
39.07 KB,
image/png
|
Details | |
56.18 KB,
image/png
|
Details | |
47 bytes,
text/x-phabricator-request
|
wsmwk
:
approval-comm-beta+
|
Details | Review |
People who have used OpenPGP in the past and who migrate to the new OpenPGP code, will probably have verified some keys of other people. The usual mechanism to remember the verification is to use your own secret key to sign/certify that public key.
Currently, we won't accept those keys automatically, they are treated as "undecided".
This bug suggests to enhance our implementation in the following way:
If we need to know the acceptance status of a public key, and the key is still in the "undecided" state, then perform an analysis of the certifications.
For each certification, check if it was made by any of the (still valid) secret keys that the local user has locally available. If yes, and the signature is valid, then treat the public key as "verified".
Because this is an expensive operation, we may cache the user's acceptance decision (in our sqlite table that's used to remember the user's acceptance decision).
Once this is discovered, we probably shouldn't allow the user to mark the key as "undecided" or "unverified" any longer. We might still allow the user to make the key as "rejected" (and figure out what action we should perform on the old key signature).
It seems this is a very important functionality for anyone migrating.
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
It's necessary to mention a complication and we need to decide how to handle it.
You don't sign someone public key's. Rather, you sign someone's user ID that's associated to a public key.
A public key can have multiple user IDs attached, with different email addresses.
Example: Bob's key has two email addresses, bob@corp.example.com and bob@fun.example.org
When Alice signed Bob's key, she might have signed the corp address, but did not sign the fun address.
There are several reasons why Alice might have signed only one key.
- Bob might have asked for the corp address to be signed, but didn't ask for the fun address
- Alice might have decided she doesn't know if the fun address really belongs to Bob
- At the time Alice signed the key, the key might not yet have contained the fun address, Bob might have added that user ID later
In this example, which email addresses should Thunderbird treat as accepted?
If we decide to accept the corp address, only, then we might need a more complex user interface for the key acceptance.
Today, the key details and acceptance dialog uses a simplified approach.
When viewing a key, we show all email addresses in a list, and ask to decide.
If the user accepts the key, then we remember that for all email addresses that are currently shown.
If the key gets updated (a more recent version of the key is imported), user IDs might have been removed or added.
If a key was removed, our code already handles that - we no longer treat removed keys as accepted.
If a new key was added, then we don't accept that key yet.
However, our user interface will not show that yet.
Rather, today's UI will show the overall acceptance status for the key's fingerprint, and will not show the status for the individual email addresses.
Today, if the user confirms the new dialog (e.g. keeping an existing "yes" choice), we will update the set of accepted email addresses to include any new addresses.
Let's look at the scenarios in detail:
(1)
We have the simple scenario, which will cover many users:
- the foreign public key has only one user ID
- the single foreign user ID is signed by the local user
We can automatically accept the signed user ID and disable choices for "undecided" and "unverified".
(2)
The foreign public key has multiple IDs / email addresses, but all of them have been signed by the local user.
We can treat this identically to scenario (1).
(3)
The foreign public key has multiple IDs / email addresses, but only a subset has been signed by the local user.
Can we find a reasonable strategy to handle this in a simplified way?
Assignee | ||
Comment 2•4 years ago
•
|
||
(In reply to Kai Engert (:KaiE:) from comment #1)
(3)
The foreign public key has multiple IDs / email addresses, but only a subset has been signed by the local user.
Can we find a reasonable strategy to handle this in a simplified way?
I suggest the following (initial) strategy:
We accept all signed/certified email addresses as accepted/verified.
All other emails listed in this key are treated as "undecided".
In the key details dialog, we append something to each user ID string shown, like [certified by yourself].
In the lower area, in the "your acceptance" tab, we don't show the usual radio buttons.
Instead, we show a special text:
"You have certified some of the user IDs contained in this key, as indicated above. The certificated email addresses will be treated as accepted and verified. The remaining email addresses will be treated as not accepted."
The idea is, state that we currently have a limitation. Potentially, we could have a more advanced UI for this in the future. I'm hoping this scenario is rare.
Assignee | ||
Comment 3•4 years ago
|
||
I think we'll need to migrate GnuPG's ownertrust setting for secret keys, at least partially.
I was thinking about how to implement this bug.
Should we really trust all signatures that were made by any secret key the user has in possession?
It seems we shouldn't, because it could allow an attack vector.
Let's assume Eve wants to trick Alice. Eve wants to read the encrypted emails that Alice sends to Bob.
To achieve that, Eve sends a fake key to Alice, which contains Bob's email.
Usually Alice wouldn't accept that fake key (not automatically).
However, Eve could create a new secret key, with an arbitrary user ID, let's say in the name of Charlie.
Eve uses the fake Charlie key to sign the fake Bob key.
Now Eve sends the two fake keys to Alice:
- the fake public key for Bob, signed by the Charlie key
- the fake secret key for Charlie
Eve might be willing to import both keys, and might not notice that she is importing a secret key (in Charlie's name).
If we automatically trusted all signatures made by any owned secret keys, then the presence of the fake Charlie key would have the result of automatically trusting the fake Bob key as accepted.
It shouldn't be possible to trick Alice simply by getting her to import a secret key.
How should we prevent that?
I tried this attack with GnuPG. Apparently, when GnuPG created a secret key locally, it is set to ultimate ownertrust.
However, if a secret key is imported that was created elsewhere, the key isn't marked as ultimately, it's marked with an unknown trust level.
Even if I export an ultimately trusted secret key, and then restore it into a fresh keyring, the secret key is no longer ultimately trusted.
So, GnuPG doesn't fall for this potential attack scenario. Rather, GnuPG (apparently) requires that a secret key is marked as "trusted to sign other keys".
I think we must do something similar in TB, and allow the user to configure which of the user's own secret keys are trusted to sign and thereby automatically accept the public keys of other people.
If my thoughts make sense, and we agree this trust attribute for secret keys is required, then a migration from GnuPG should also import those existing trust attributes.
Assignee | ||
Comment 4•4 years ago
|
||
Patrick, does comment 3 make sense? Any additional thoughts, or details that I'm missing?
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
The current (new) TB implementation will automatically accept a key, if the secret key is available. So, Eve can trick Alice to accept Charlie's key, simply by sending a fake secret key to Alice, and convincing Alice to import it. In that case, we don't ask Alice to confirm or verify that it's really Charlie's key. That a security issue, we need to change how this works. (That's independent of this enhancement bug for processing key signatures.)
Assignee | ||
Comment 7•4 years ago
•
|
||
Our intention is to make this easier to understand than in other software. For example in GnuPG, a key is accepted as a personal key, if the user marks its ownertrust as ultimate.
It took me a lot of brainstorming to come up with a solution that I like.
I suggest that following text for the "Your Acceptance" tab, if both secret and public key are available.
==================
For this key, you have both the public and the secret part. This usually means that it is your personal key. A personal key is treated specially, and can be used to influence which keys of other people you automatically accept.
Do you accept this key as your personal key?
If a key was given to you by someone else, then don't accept it as a personal key.
- No, don't accept it as my personal key.
- Yes, this is my personal key. I have created it myself, and the displayed key ownership refers to myself. If this personal key is used to certify another key, then automatically accept that other key as verified.
==================
Assignee | ||
Comment 8•4 years ago
•
|
||
Further explanation of intentions:
If Thunderbird is used to create the user's personal key, we automatically mark the key as "yes this is my personal key".
If the user imports a personal/secret key, then the import procedure should ask the user for a confirmation that it is really a key the user has created on their own, and is restoring it from a backup - or - if the key has been given to the user by someone else (possibly in an attempt to trick them).
So, when importing a secret key using the new wizard from bug 1627736, I think we should offer the above explanation and choice, and default to "don't accept".
Assignee | ||
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Under which circumstances would you ever be "given both the public and secret key of someone else"?
Assignee | ||
Comment 10•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #9)
Under which circumstances would you ever be "given both the public and secret key of someone else"?
With the current experimental implementation, Thunderbird fully accepts a secret key, without asking the user to accept/verify it.
Knowing this, an attacker could send victim Alice a fake key in the victim Bob's name. Instead of a public key, they could send a secret key. They could convince Alice to import it using the key manager.
If Thunderbird behavior stays this way, then this could be an approach to trick users into accepting fake keys, circumventing the "acceptance" safeguards in the user interface.
Comment 11•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #9)
Under which circumstances would you ever be "given both the public and secret key of someone else"?
For example if you use a mailing list with a (relatively small) list of known users. If you want to encrypt mails, and not use something like Schleuder, then the simplest thing is to create a specific key to use for encrypting to that list, and you share the secret key among all subscribers.
Assignee | ||
Comment 12•4 years ago
|
||
After more brainstorming, I think we should do the following:
- Have separate settings for (a) "I accept this as a personal key" and (b) "I want to automatically accept other keys that are certified by this key".
- GnuPG seems to combine the settings for both (a) and (b) into a single choice, being "ownertrust = ultimate". This is problematic in the scenario that Patrick mentioned in comment 11. If people do that, they probably want to be able to send email to that address, so they'd need (a) = true. However, if Alice and Eve share the secret key, then Eve could use the key to sign a fake key in Bob's name, thereby tricking Alice to automatically accept it. For that purpose, I think it makes sense to have setting (b) separate.
- At this time, we'd set (b) for all imported keys that have ownertrust = ultimate set.
- Although we need to allow (b) for personal keys, there's no reason why we'd have to restrict it to personal keys. We could consider to allow any key of anyone else to be acceptable for (b). I'd suggest that we limit the ability to set (b) = true to keys that have acceptance level "verified".
- Doing the above would satisfy the request to support certification keys.
In order to implement the above, I suggest to introduce an additional tab in the key details/properties dialog.
The new tab could be called "Certification Acceptance".
(I wouldn't call it ownertrust, because we don't fully follow the model that GnuPG uses for ownertrust.)
If a key (pair) is accepted as a personal key, or if the shown (public) key is in acceptance level "verified", we'd offer the following choices:
- Don't automatically accept other keys that are certified by this key.
- If this key is used to certify another key, then that other key is automatically accepted as verified.
If the is neither accepted as a personal key and isn't verified, then the tab would display an information message saying:
"This functionality is available for personal keys and verified public keys, only."
The choices would still be shown, but disabled, and the "don't" choice is selected.
This approach allow us to migrate all ownertrust flags from GnuPG at the time of Enigmail migration.
We could store all flags as they are set in GnuPG.
We might limit the initial implementation (shortage of time) to personal keys, and consider the other details for later, including decisions about indirect trust.
Assignee | ||
Comment 13•4 years ago
|
||
Patrick, what's your opinion about comment 12 ?
Comment 14•4 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #12)
I agree that this is the most flexible choice. But maybe we should name it a little differently (from the user's perspective):
(a) this is a private key I own myself and that I have fully under my control
(b) this is a private key that is shared among several people and/or that I don't trust entirely
Assignee | ||
Comment 15•4 years ago
|
||
Patrick, thanks for your general agreement. The wordage in comment 14 might not be ideal, we probably shouldn't tell people about the possibility of sharing keys. They might incorrectly conclude that as a reasonable thing to do - while we probably shouldn't encourage sharing of secret keys.
Assignee | ||
Comment 16•4 years ago
|
||
I have a bigger patch ready, that implements suggested UI, the required backend storage, and the interdependencies between controls.
It's still missing the complete automatic checking if a key should be automatically accepted, and the relevant status.
But it might be good to get started with this work.
Ideally, I'd like to have this landed before the 78 release - to enable Patrick to migrate existing GnuPG ownertrust flags into our new storage.
Assignee | ||
Comment 17•4 years ago
|
||
For comparison, this is the current/old display of the "your acceptance" tab, whenever we find we have a secret available.
As explained above, we want to change that.
Assignee | ||
Comment 18•4 years ago
|
||
New display for acceptance tab, if personal key is available.
User is able to mark a key as "not my key" or "yes this is my key with my identity and I created it myself" - to distinguish from keys, that the user might have imported, but has been given by someone else.
The idea is to automatically set this flag to "yes" whenever we generate a key inside Thunderbird.
When importing a secret key, the user should be asked to make that choice.
Assignee | ||
Comment 19•4 years ago
|
||
This patch introduces a new tab, currently named "Indirect Accptance".
If you look at a key pair (have secret key) and the user has confirmed it's a personal key, then we get this display - which offers the user the choice to automatically accept certified keys.
Assignee | ||
Comment 20•4 years ago
|
||
In contrast to the previous image - if you're looking at a secret key, but the user has rejected the "is a personal key" flag, this is what you get in the "indirect acceptance" tab. - You are not allowed to mark it as "accept certifications".
Assignee | ||
Comment 21•4 years ago
|
||
This is shown for a public key (someone else's key) that you haven't verified. You aren't allowed to mark it to automatically other keys.
Assignee | ||
Comment 22•4 years ago
|
||
In contrast to the previous image, if you have verified another person's public key, you are able to mark it as "automatically accept other keys that were certified by this one".
Assignee | ||
Comment 23•4 years ago
|
||
Finally, this is for a public key that isn't valid any more, obviously you cannot use it to trust anyone else.
Assignee | ||
Comment 24•4 years ago
|
||
Assignee | ||
Comment 25•4 years ago
|
||
When migrating ownertrust from GnuPG, the suggestion is to:
- migrate "ultimate" into calls to RNP.acceptAsPersonalKey(fingerprint); and RNP.updateTrustedVerifier(fingerprint, "full");
- migrate "full" by calling RNP.updateTrustedVerifier(fingerprint, "full");
Don't make a call if ownertrust has any other value, because they wouldn't have any effect with our implementation.
I'm slightly undecided if migrating the other ownertrust flags make sense - because if it's a one time import, then those flags sit in our storage for a year without being used. If the user uses GnuPG in parallel, they might make changes to those flags in GnuPG, and our storage gets out of sync.
So, if we'll ever want to offer users to make use of more indirect trust, then maybe we should work out a synchronization of flags from GnuPG at a future time.
Assignee | ||
Comment 26•4 years ago
|
||
We cannot implement this at this time, because RNP doesn't yet support checking the validity of signatures on a key.
I'll mark this bug as a feature enhancement, and will file a separate bug for marking secret keys as personal keys (or not).
Assignee | ||
Comment 27•4 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #26)
I'll mark this bug as a feature enhancement, and will file a separate bug for marking secret keys as personal keys (or not).
No. Let's change this bug into only handling "mark as personal" key, because 70% of the attached patch are about that.
I'll update the revision, to only be about that.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 28•4 years ago
|
||
Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/5fed4272e44c
Ability to mark key pairs as "accepted personal keys" or not. r=PatrickBrunschwig
Assignee | ||
Comment 29•4 years ago
|
||
Comment on attachment 9158530 [details]
Bug 1642795 - Ability to mark key pairs as "accepted personal keys" or not. r=PatrickBrunschwig
This is an important change to OpenPGP, that makes additional flags available, that need to be set by the Enigmail migration tool.
Comment 30•4 years ago
|
||
Comment on attachment 9158530 [details]
Bug 1642795 - Ability to mark key pairs as "accepted personal keys" or not. r=PatrickBrunschwig
Approved for beta
Assignee | ||
Comment 31•4 years ago
|
||
Updated•4 years ago
|
Description
•