Remove import-key facilities (by file and through incoming Autocrypt Setup Message)

[hpk42]

It's time to remove the ability to import keys through primary or advanced settings in Delta Chat to prevent breakage for users and complications for future development.

Importing OpenPGP keys (by file or ASMs) has the following limitations and problems today:

• green-checkmarked groups will break and cause [The message was sent with non-verified encryption. See 'Info' for more details] errors for users.

• password protected keys can not be imported

• security audits have not and do not cover all possible importable OpenPGP keys and their algorithms. Allowing to import arbitrary OpenPGP keys is not safe, and it is hard to ascertain implementation security through audits.

• migrating to v6 keys in the future is more complicated if we need to consider migrating from arbitrary keys that came from user imports instead of the RSA/ED25591 ones that Delta Chat generates, in compliance with the Autocrypt spec.

Moreover, very few Delta users even think of manually managing OpenPGP keys, and if they try it, they quickly run into one of the above problems, as happened in some chat groups lately, leading to friction and invalid messages in those groups and debugging time spend to investigate it.

One known objection against removing import-key facilities is that it degrades shared-address interoperability in the sense that multiple different e-mail apps/MUAs can not share an encryption setup for the same e-mail address anymore (however, exporting a key or sending an Autocrypt Setup Message remains available, and e.g. Thunderbird users may thus import keys exported from Delta Chat). But there are hardly any real-world practical usages of shared-address E2EE interoperability today, other than for debugging and expert/developer use cases. After all, sharing a messenger-interface like Delta Chat's with a regular Recipients/Subject-based classic e-mail program anyway causes friction, even without e2ee encryption. For example, Delta Chat does not, like other MUAs, present an "IMAP-folder" view but rather uses IMAP folders to receive messages and generally does not look at received messages later again. Shared-address interop is therefore limited today, and not bound for improvements soon, independent from the import-key issue.

Note that Delta Chat is and remains interoperable in two cruicial ways, it is

• messaging-interoperable with other MUAs through the use of e-mail addressing and transports, and the use of OpenPGP/Autocrypt encryption and standard MIME messages;

• server-interoperable in that it can work with different standard SMTP and IMAP servers.

[link2xt]

Related Android issue deltachat/deltachat-android#3591

[ell1e]

The things I said in person were 1. it'd be nice if making a new identity with the same email but a new key worked to make migrating easier (and also perhaps starting over in case the identity key leaked), and 2. perhaps some sort of low frequency identity key rotation over the long term, like e.g. every few years or after the user reports a suspected but not abused yet leak, might have some advantages from a security angle. And identity key revocations would be nice too.

[hpk42]

The things I said in person were 1. it'd be nice if making a new identity with the same email but a new key worked to make migrating easier (and also perhaps starting over in case the identity key leaked), and 2. perhaps some sort of low frequency identity key rotation over the long term, like e.g. every few years, might have some advantages from a security angle. And identity key revocations would be nice too.

This issue is not about collecting new wishes for key-management but about removing UI to import keys :)

[ell1e]

Oops, my bad! 😮

[link2xt]

I am changing the core to make it impossible to change the default key (the one used for signing and sent in Autocrypt header) once you have one already: chatmail/core#6574
This will solve the problem of users changing the key on profiles that are already part of some groups and prevent [The message was sent with non-verified encryption. See 'Info' for more details].

It will still technically be possible to use a custom key as long as it is imported before Delta Chat generates one. We need this for tests, but it will also be possible in bots and for deltachat-repl testing.

security audits have not and do not cover all possible importable OpenPGP keys and their algorithms. Allowing to import arbitrary OpenPGP keys is not safe, and it is hard to ascertain implementation security through audits.

For security audits we can say that non-Autocrypt keys (e.g. ones that consist of a single primary RSA key that is used both for encryption and signing) are out of scope, this is not a problem.

[hpk42]

I am changing the core to make it impossible to change the default key (the one used for signing and sent in Autocrypt header) once you have one already: deltachat/deltachat-core-rust#6574 This will solve the problem of users changing the key on profiles that are already part of some groups and prevent [The message was sent with non-verified encryption. See 'Info' for more details].

Usability question still remains what someone expects if they are encrypting to you with your "non-default" key ... If we are just using our "default" key to sign the reply-message, then they might not have our identity key, and it just doesn't really succeed for users.

Virtually all use cases about import-key are about someone playing with it because it's possible to do so.
Sharing Delta Chat with mutt or even Thunderbird on the same e-mail address is hard to enjoy (who really does it?) --
Besides one can edit a backup file or write a thunderbird->delta conversion tool that produces a backup file that you can import into Delta Chat. This is far more interesting and useful than fiddling with secret PGP keys and passing them through a world-readable Downloads folder on mobile etc. and teaching everybody how to do this carefully.

It will still technically be possible to use a custom key as long as it is imported before Delta Chat generates one. We need this for tests, but it will also be possible in bots and for deltachat-repl testing.

security audits have not and do not cover all possible importable OpenPGP keys and their algorithms. Allowing to import arbitrary OpenPGP keys is not safe, and it is hard to ascertain implementation security through audits.

For security audits we can say that non-Autocrypt keys (e.g. ones that consist of a single primary RSA key that is used both for encryption and signing) are out of scope, this is not a problem.

If anyone that has imported a broken key and then enters a group chat of 10 people, it corrupts everybody's messages in the group, i.e. makes them readable or worse. Restricting PGP keys to very specific algorithms and combinations better minimizes the attack surface.

[Hocuri]

Discussion has somewhat stalled - to summarize:

• In this issue here, @hpk42 proposed to remove "import-key-file" and "receive-asm" (asm = autocrypt setup message).
• In Remove "Encryption" section from chatmail profiles deltachat-android#3591, @link2xt proposed to remove all key operations for chatmail. There also is an open PR for that.
• In fix: make it impossible to overwrite default key chatmail/core#6574, @link2xt already made it so that the default key cannot be overwritten; you can only import keys before you sent the first message. Therefore, for multi-transport everything is fine already. The other reasons @hpk42 posted above still apply.
• In this issue, noone posted any arguments against removing import-key-file and receive-asm. In Remove "Encryption" section from chatmail profiles deltachat-android#3591 (comment), @dkg argued in favor of keeping receive-asm.
• Someone proposed that we should also remove remove export-key-file on mobile (because it's unsafe to export it without password protection into the Downloads folder; it can stay in DC Desktop then)

(Off-topic: BTW, there was also no conclusion on whether some settings should only be available in non-chatmail profiles but hidden in chatmail profiles at all, or whether we should phase out this distinction between chatmail and non-chatmail. I guess that if we decide yes, then profiles with multiple transports will also count as "chatmail profiles".)

[hpk42]

I'd like to keep the focus here on import-key facilities in UIs. Let's finalize this issue here and indeed remove import-key from all UIs. Right now, there is hardly any other MUA that sends an ASM to Delta. FairEmail recently dropped the plan to support ASMs ... search for "autocrypt setup" in their support page https://m66b.github.io/FairEmail/ Lastly, we generally recommend users these days to use dedicated e-mail addresses and not an e-mail address that is shared between different MUAs. If anything, we could revive some form of an ASM message in Autocrypt Level 2 or so but it would better then also include contacts and their keys, and be quantum-resistant ;)

[Hocuri]

+1 from my side in favor of going forward & removing both importing key files and receiving ASMs. It's sad about receiving ASMs, but reality is that apart from DC, only a niche email client that only speaks JMAP supports it. And after all these years it's unlikely this will change all of a sudden just because DC continues supporting it (with DC being the only client for which it doesn't actually make sense to support it, because DC isn't a fully-featured MUA but a messenger). At some point we need to accept that the idea was nice, but it didn't actually work out.