Autocrypt support for kmail
Open, Needs TriagePublic

Description

Autocrypt makes it easier to communicate end-to-end encrypted via mail. Thhe basic idea is to have a additional mail header "Autocrypt". Within this header you send your gpgkey and your encryption policy. The goal is to have everytime the gpgkeys you need to reply.

They also added a way to transfer your secret gpgkeys between devices.

for sending mails

Autocrypt uses a special header named Autocrypt with the complete keymaterial It is quite straightforward to just add this header to a mail we want to send. With following format:

Autocrypt: addr=alice@a.example; prefer-encrypt=mutual; keydata=...

later on we want also add the Autocrypt-Gossip header to support 1:N communication.

for retrieving mails

to make usage of Autocrypt we need to understand the autocypt headers and interpret them correctly. This is a more advanced task, as more parts in KDE PIM needs to been touched. Additionally we need to think about how we dispaly the information to the user. Especially if the keys differ from what we have in the keyring.

knauss created this task.Apr 3 2018, 9:24 AM

I'm not against it as such. Anything to grow and improve the OpenPGP / Mail Crypto ecosystem is good as long as it is compatible. But I do not like the Autocrypt concept very much.

The design decisions of Autocrypt were / are made on private meetings. We tried to argue / discuss the concepts in mails and were mostly ignored.
I don't see the need to send a public key in the header, If a MUA sends signed mails by default and a key is published either through WKD or on a public keyserver it is redundant and enlarges the mail without necessity. If you have a signed mail you already know the fingerprint of your communication partner and can grab that from a keyserver.

Similarly I find it more important to track if you have received a signed mail from a communication partner, then you can be pretty sure that you can encrypt a mail to that key and the communication partner can read it. Autocrypt also does not make any assertions about trust. As I understand it they declare trust out of scope and only want to promote encryption by default. Don't get me wrong, this is a good goal. But I think that we can do more.

Speaking for the GnuPG Project, our favorite concept is still https://wiki.gnupg.org/AutomatedEncryption even with the projects for this finished we are still working on it based on donations. For Gpg4win 3.1.0 I've started with a new Keyresolver in Libkleo, as a first step it does not do much more then what is really required for our Outlook Mail Extension. The change to this was already traumatic enough ;-). But for 3.2.0 we are planning to extend this further to have more automated encryption support. The API is designed in a way that should allow KMail / KAddressbook integration. Maybe take a look at libkleo/src/kleo/keyresolver and libkleo/src/ui/newkeyapprovaldialog .

One of the things we are missing in GnuPG for example would be to have it change the trust model for a Context, as I don't see how you can provide a good user experience with "TOFU" trust for file crypto, but I want to use it for Mail crypto.

knauss updated the task description. (Show Details)Aug 19 2018, 1:12 PM

I'm also with you aheineke, that this Autoencrypt is not the smartest solution for email encryption. As Thunderbird already sends those headers it is very good if we support it, too. And I see some gain in some usecases where Autoencrypt makes the life easier.

knauss moved this task from incoming to Technical on the KDE Privacy Goal board.Mar 25 2019, 9:13 PM

As Thunderbird and k9-mail (Android) support autocrypt it would certainly make things a little easier when using email encryption and making it a little easier isn't a bad thing.

Whishlist bug report about autocrypt support:

Bug 388036 - Include support for autocrypt
https://bugs.kde.org/388036

Good to close in case of implementation.

Encouraged by the Junior label and heliosmartins reference, I'm looking into the Autocrypt spec to see if this is something I could do (I do not know what the Junior label specifically means or how it was determined). Adding a header to all outgoing emails seems fairly straightforward. For retrieving mails, which was classified as 'advanced' in the task, I'm trying to flesh out the work needed a bit more. I have zero Kmail or KDE coding experience (a bit of C++ I do). The Autocrypt spec does seem quite well worked out such that I only have to think about the best integration into Kmail.

With regards to updating keys: the default behavior in the Autocrypt spec seems to be to auto-overwrite the previous key in case of receiving a new key (in a message which meets all the requirements to prevent auto-accepting a wrong key). See bottom of this section.

I think the main thing is that Kmail now uses an external PGP client, and PGP trust levels. Autocrypt has no trustlevels afaics (just the binary prefer_encrypt), but Enigmail and K9mail implemented a trust level on top of that (one can chose to trust a key, which then drops to untrusted upon the auto-overwrite of a new key. Is it necessary to map this to the 6 trustlevels of PGP, or should Kmail keep this 'rating' separate and only use the PGP client as a keystore?

Since auto-overwriting keys are Autocrypt spec, I suppose the enabling of Autocrypt is MUA-wide, not, for instance, per identity. If Autocrypt support is enabled upon a new checkbox under Identity > Crypto, another identity may still override the key of a communication peer which is perhaps communicated with another 'non-autocrypt identity'. I think this solves the all possible conflicts between Autocrypt defaults and PGP defaults or expectations: by enabling Autocrypt the user gave consent to these behavior MUA-wide.

Another question is how this task relates to T2520, which is about opportunistic encryption. I don't know if any code came from that, but I guess the same sort of GUI implementation for trust-levels could and should be reused.

What are your thoughts?

Encouraged by the Junior label and heliosmartins reference, I'm looking into the Autocrypt spec to see if this is something I could do (I do not know what the Junior label specifically means or how it was determined). Adding a header to all outgoing emails seems fairly straightforward.

"Junior label" means, that the task is straightforward and you don't have to touch many kdepim repos. And yes adding a header to all outgoing mails is straighforward.

For retrieving mails, which was classified as 'advanced' in the task, I'm trying to flesh out the work needed a bit more. I have zero Kmail or KDE coding experience (a bit of C++ I do). The Autocrypt spec does seem quite well worked out such that I only have to think about the best integration into Kmail.

With regards to updating keys: the default behavior in the Autocrypt spec seems to be to auto-overwrite the previous key in case of receiving a new key (in a message which meets all the requirements to prevent auto-accepting a wrong key). See bottom of this section.

this auto-overwrite behavior is exactly the one, that is hard nut to solve. Because the Autocrypt header is neither signed nor encrypted, so it is obvious how to do a man-in-the-middle attack. That means if you have an ongoing encrypted communication without Autocrypt, nobody can simple change your keys. This means Autocrpyt is lowering the security of such a communication.

Another issue Autocrpyt by default, do only encrypt, if both ends of the communication have signaled, that they prefer encryption. That's why if you communication with old behavior kmail is encrypting, because it finds a key for the recipient. Now you switch on Autocrypt and don't received any Autocrypt by your communication partner yet, so Autocrypt will end out unencrypted mails. And this happened with people using Thunderbird, because of Autocrypt they send unencrypted mails.

I think the main thing is that Kmail now uses an external PGP client, and PGP trust levels. Autocrypt has no trustlevels afaics (just the binary prefer_encrypt), but Enigmail and K9mail implemented a trust level on top of that (one can chose to trust a key, which then drops to untrusted upon the auto-overwrite of a new key. Is it necessary to map this to the 6 trustlevels of PGP, or should Kmail keep this 'rating' separate and only use the PGP client as a keystore?

well everyone using external PGP client ;D With Autocrypt in place, we need a separate store, where we hold settings for recipients etc. We should not try to map Autocrypt to the trustlevels, as those are not connected to Autocrypt and users will hate use, if we change trustlevels, they have setup manually.

Since auto-overwriting keys are Autocrypt spec, I suppose the enabling of Autocrypt is MUA-wide, not, for instance, per identity. If Autocrypt support is enabled upon a new checkbox under Identity > Crypto, another identity may still override the key of a communication peer which is perhaps communicated with another 'non-autocrypt identity'. I think this solves the all possible conflicts between Autocrypt defaults and PGP defaults or expectations: by enabling Autocrypt the user gave consent to these behavior MUA-wide.

Autocrypt support needs to be by identity, because you need to specify for each identity if you prefer encryption ( what is a MUST from Autocrypt spec).

Another question is how this task relates to T2520, which is about opportunistic encryption. I don't know if any code came from that, but I guess the same sort of GUI implementation for trust-levels could and should be reused.

This is another project named EasyGPG that is trying to make it easier to communication encrypted. But keep in mind, we can't simple select some parts of Autocrpyt and merge the rest with something else.

[spam comment removed by sysadmin]

@knauss Thanks for your elaboration.

Regarding the externality of the PGP client: a few tools I know use an internal (OpenPGP.js I am sure) library when set to Autocrypt mode. Enigmail as of version 2, when in the default easy mode, did not appear to store keys in the external client (when autocrypt is enabled) but somewhere internal (you can find openpgp.js in the Enigmail sources). The pEp mail client's the same, and a new Thunderbird client 'AutoCrypt' that does not offer a regular PGP mode also won't use any client you may have installed.

So, at least some MUA's appear to not use external PGP clients when Autocrypt is enabled. That may be because there is no other solution to the problem of auto-overwriting keys than seperating modes: in regular PGP you never want this to be done automatically, in Autocrypt mode you always want this to be done automatically. That also removes the need to map trustlevels.

Then, as your last sentence implies: Autocrypt must be a separate mode, and not maintain or even use an existing clients keys/identity. Would you agree?

Incidentally: how are keys of different identities now separated? I have two identities and I use Kleopatra, but I can't see in Kleopatra which keys one identity trusts and another doesnt?

Regarding the externality of the PGP client: a few tools I know use an internal (OpenPGP.js I am sure) library when set to Autocrypt mode. Enigmail as of version 2, when in the default easy mode, did not appear to store keys in the external client (when autocrypt is enabled) but somewhere internal (you can find openpgp.js in the Enigmail sources). The pEp mail client's the same, and a new Thunderbird client 'AutoCrypt' that does not offer a regular PGP mode also won't use any client you may have installed.

Enigmail has an issue, that it can't rely on a recent version of GnuPG, that's why they ship an OpenPGP.js. At KMail we have recent GnuPG so no need to bundle a js version. You you give me a good ide, to just use a differnt keyring for Autocrypt, that solves the issue, that Autocrypt will interfere with the normal keyring.

Incidentally: how are keys of different identities now separated? I have two identities and I use Kleopatra, but I can't see in Kleopatra which keys one identity trusts and another doesnt?

The normal GnuPG mode, has no idea of identities, so you can only trust a key or not, if a key is trusted than you can use it globally.

Separate keyrings is indeed what I meant, it's what at least some clients do. I don't think gpg supports multiple keyrings though, so you'd need to include a lib.