Open Bug 1665570 Opened 4 years ago Updated 1 year ago

[OpenPGP] Allow a WKD key to be used without manually accepting it.

Categories

(MailNews Core :: Security: OpenPGP, defect, P2)

Tracking

(Not tracked)

People

(Reporter: kenny, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Safari/605.1.15

Steps to reproduce:

I updated to Thunderbird 78.2.2

Actual results:

Key management has become a UI/UX nightmare with click paths through several dialogs before a key is trusted and a message can be sent. Keys aren't retrieved automatically via WKD and not trusted by default anymore, which is the whole point of WKD. If I tried to prevent people from using encryption, that's how I would implement it.

Expected results:

The UI/UX shouldn't be a nightmare, automatic key retrieval mechanisms should work as expected and trustful sources should be handled as such. There should at least be the possibility to set a configuration option to improve the usability. As it stands, the current implementation is unusable for larger corporations that have rolled out GPG mail encryption.

Component: Security → Security: OpenPGP
Product: Thunderbird → MailNews Core

Probably a duplicate of bug 1662282.
From a UI and UX point of view, we're going through iterations to improve all these aspects and the last big one that I need to tackle is the Key Manager dialog, which is not intuitive and needs a complete rebuild.

Keys aren't retrieved automatically via WKD and not trusted by default anymore, which is the whole point of WKD

I let Kai speak about this as I'm not sure if it's something we specifically decided to do.

Flags: needinfo?(kaie)

It was mostly me who deliberately decided that it should be that way.

If WKD is used on a large's organization's server, automatic accepting downloaded keys would expose users to the risk, that the server's administrator could have configured a fake key for a particular user that should be targetted for an MITM attack.

Regardless of source of key, I think it makes sense to require users to make a decision once, if they are willing to accept a key without manual verficiation, or use the reminder as an opportunity to perform a manual verification.

Flags: needinfo?(kaie)

(In reply to Alessandro Castellani (:aleca) from comment #1)

Probably a duplicate of bug 1662282.

No, this bug is a general complaint about having to do too much manual work before a key can be used.

I think the real request of this ticket is:

Summary: [OpenPGP] Improve key management usability → [OpenPGP] Allow a WKD key to be used without manually accepting it.

I think the real request of this ticket is:
Allow a WKD key to be used without manually accepting it.

I think we shouldn't allow that, because of my explanation in comment 2

I do not think that this is a fitting approach for organizations. Checking the integrity of keys is nothing that a typical non-technical user is able to do in a secure way and is also beyond the complexity that seems acceptable for an organization. The whole point of corporation-wide central key directories (like WKD) is that the source of the key should provide enough trust to use the corresponding key (see chapter 3 of https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-10 for comparison). Even if this is not allowed by default for all WKD sources, there should at least be the option to trust all keys received via WKD for a configurable (list of) domain(s) to enable seemless intraorganizational encrypted communication. Again, manually trusting all keys within an organization is infeasible.

See Also: → 1675007

There's a lot to be done in improving the composition workflow for sure. We should make it easy to do key discovery if keys are used for the first time, using some wizard type approach to guide the user. They could then be offered to start using the key found from WKD and basically click ok. After that only the accepted key should be used. Possibly we should notify if we find updates through WKD, but that's something for later.

A MITM key replacement is not a serious risk since anything being sent that is sensitive enough for your own domain to MITM you will likely be using manually exchanged and verified public keys.

Automatic WKD discovery without manual confirmation has way more benefits than the low risk of your own domain targeting you.

The only manual prompt should be to replace an existing public key.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2

To automatically accept the key found via WKD would fit to the strategy with the UI redesign. There you try to make it very user-friendly and give experienced users the options to set different settings.
Here you could also accept the key automatically (beginner-friendly) and add an option in the settings to disable this behavior.

Should the type of this report not be "enhancement"? At least it's not a bug.

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