Feature: Autocrypt email encryption

[seifferth]

I see that mutt has not only added multipart/alternative generation filters (cf. #58), but also Autocrypt capabilities. Maybe we could add Autocrypt to bower as well? Of course, in bower's case, Autocrypt would have to work in tandem with notmuch. I haven't checked the state of things on that side yet, just bringing up the idea.

[xxxserxxx]

From the other ticket, which was erroneously opened in ignorance of this one:

Link to the Autocrypt specification.

My suggestion is to not add a config option, but set the Autocrypt header based on whether the user configured PGP settings.

[seifferth]

There has been some discussion on adding autocrypt to notmuch already:

https://www.mail-archive.com/notmuch@notmuchmail.org/msg47564.html
https://www.mail-archive.com/notmuch@notmuchmail.org/msg50798.html

I would tend to agree with the second message that suggests implementing this directly as part of notmuch. Simply adding an autocrypt header to messages would be pretty easy to do in bower, yet most of autocrypt seems to come down to automatically handling those headers in incoming mail, maintaining a database of public keys received via autocrypt headers, and using those keys to automatically encrypt outgoing email. The latter part is probably out of scope for a notmuch frontend like bower.

The second thread linked above hints at the possibility of notmuch providing a filter to encrypt outgoing messages based on autocrypt:

It's possible that [emacs frontend work] could be replaced with a new subcommand like "notmuch send" which could have a "--autocrypt-checked" argument, such that the notmuch cli actually does the full encryption for the user, or acts as some sort of filter for the outgoing message.

If notmuch provided such a filter (as notmuch send --autocrypt-checked, for instance), that receives a non-encrypted message on stdin and produces a possibly encrypted message with additional autocrypt headers on stdout, this functionality could be used in bower. It might be as simple as changing

sendmail = msmtp

to

sendmail = notmuch send --autocrypt-checked | msmtp

in the config file (not verified, though). Or we might decide to add this filter to all outgoing messages. That way, it might even be feasible to delegate autocrypt configuration to notmuch altogether.

[xxxserxxx]

notmuch can only index decrypted messages; people who are concerned about infosec will set an appropriate decrypt_policy to prevent indexing cleartext (because Xapian databases are not encrypted). Arguably, this group of people are also the most likely to want to use encrypted email and Autocrypt -- while this would be fine for many people, who are only concerned with encryption-in-transit, delegating this to notmuch would be a worse outcome for the most vulnerable people who are also concerned about encryption-at-rest. They would not be able to use Autocrypt at all. I argue that, regardless of notmuch's support for Autocrypt, it is desirable for mail clients to also support it for people for whom data security is a priority.

I'm confused about what seems to be a significant scope creep in the idea of adding sendmail functionality to notmuch. libnotmuch has never been a sendmail agent.

[seifferth]

You can easily store your Xapian index on an encrypted partition. This is actually what I am doing. Both my maildir and notmuch's database live on an encrypted partition. This way I can have both full-text-search and encryption-at-rest. I don't believe autocrypt is meant to provide encryption-at-rest. The way I understand it, it is meant to provide end-to-end encryption only. Hence, as soon as the message arrives on my device (the second end of end-to-end), it is supposed to be decrypted anyhow.

Furthermore, I don't believe that "people who are [very] concerned about infosec" are the target audience of autocrypt anyhow. To quote the autocrypt specification:

Autocrypt aims to incrementally and carefully replace cleartext e-mail with end-to-end encrypted e-mail. This differs from the traditional approach of maximizing the security of individual mail communications. [...] We share and support the new perspective stated in RFC7435 (“Opportunistic Security: Some Protection Most of the Time”).

Autocrypt is still vulnerable to Man-in-the-Middle- and Downgrade-Attacks, for instance. If someone is very "concerned about infosec", as you put it, "Some Protection Most of the Time" is probably not what they want. Autocrypt doesn't supersede PGP/SMIME either, so if "some protection" is too little for you, you can still stick to those encryption protocols.

If understood as adding sendmail functionality to notmuch, I would agree that notmuch send would be a rather unexpected case of feature creep. That's why I decided to understand notmuch send as a possible pre-filter for outgoing messages ;) Maybe a naming like notmuch autocrypt prepare would be more fitting. This filter might be called as cat mail.eml | notmuch autocrypt prepare | sendmail. Notmuch would take care about opportunistically encrypting the content and adding autocrypt headers while being completely ignorant of SMTP. Sendmail (whichever one you use) would send messages, as it always has, while being blissfully ignorant of encryption.

And one last thought: I'm not sure I would even consider bower to be an email client ;) The way I see it, the actual email client is notmuch itself. Bower is only a notmuch-frontend. A wrapper around the notmuch cli which provides additional paging and some bindings like m, r or e to quickly bring up a text editor (no offence intended).

[xxxserxxx]

You can easily store your Xapian index on an encrypted partition.

Yes. Are you suggesting that storing unencrypted data on an encrypted partition is as secure as storing encrypted data on an encrypted partition?

I don't believe autocrypt is meant to provide encryption-at-rest.
...
Autocrypt doesn't supersede PGP/SMIME either, so if "some protection" is too little for you, you can still stick to those encryption protocols.

This is all true, because Autocrypt doesn't provide any encryption; it's a key exchange specification. It adds key exchange to the PGP (defacto) standard. S/MIME is a different standard and Autocrypt doesn't reference it.

It's true that no journalist in a repressive country should rely entirely on Autocrypt for key exchange; it's an addition to whatever other measures are being used, just like keeping encrypted emails encrypted on disk is in addition to encrypting the partition on which the DB is stored. All security only makes it harder to compromise, and none provides perfect security.

The notmuch decrypt_policy feature is a recognition that there are use cases for not storing unencrypted indexes for sensitive email. bower -- and other notmuch based email clients like Astroid -- manage signing and encryption outside of notmuch already. Ideally, bower will know about Autocrypt headers to be able to display markup in the UI -- key ID, exchange status, etc. It makes sense for bower to understand and deal with this regardless of notmuch's support for it.

[wangp]

I have only skimmed the Autocrypt specification so far but I think:

• bower could, if we wanted, add an Autocrypt: header on outgoing messages that match a certain From: address, if we knew what the keydata should be (presumably retrieved from GPG). I think it should be opt-in though.
• maintaining the peer state table is clearly the job of notmuch or perhaps a companion tool that inspects every message already in or entering the mail store. It's out of scope for bower and other frontends.
• bower should be able to ask notmuch (or the tool that maintains the peer table) whether or not the Autocrypt algorithm recommends to encrypt a message for a given list of recipients, and get the list of keys for those recipients.
• bower would construct the encrypted message and send the message as it does now. There's no need for notmuch to take on these tasks (but there would be advantages and disadvantages to doing so).
• if notmuch had commands for creating Autocrypt setup messages or importing from them, we might want to expose some UI for those commands eventually.
• it may be of interest to display an indication of Autocrypt: headers on messages you have received

[seifferth]

• bower could, if we wanted, add an Autocrypt: header on outgoing messages that match a certain From: address, if we knew what the keydata should be (presumably retrieved from GPG).

The autocrypt suggestion for Interoperability with existing PGP practices is to not store your own keys in the global pgp keyring. Admittedly, those recommendations still look a little unfinished, but I believe that the general idea is to keep autocrypt and other pgp practices separate as much as possible. The suggestion also mentions that it would be preferable to use non-autocrypt pgp keys if available. That would make sense, since autocrypt in general tries to establish a better than nothing baseline for encrypted email that, above all, remains easy to use, rather than aiming at bullet-proof encryption.

• maintaining the peer state table is clearly the job of notmuch or perhaps a companion tool that inspects every message already in or entering the mail store. It's out of scope for bower and other frontends.
• bower should be able to ask notmuch (or the tool that maintains the peer table) whether or not the Autocrypt algorithm recommends to encrypt a message for a given list of recipients, and get the list of keys for those recipients.

I just played around with using notmuch search a little and found that it is rather easy to (partially) generate the peer state table, as described in the autocrypt specification, on the fly. I pushed my experiments to https://github.com/seifferth/notmuch-autocrypt in case anyone else might be interested in them.

All in all, my very basic and probably rather buggy implementation provides the following commands:

• notmuch autocrypt account init <email> to generate a new, notmuch-autocrypt-specific keypair with pgp. (I'm not even confident it is valid, though, since I didn't use it to encrypt anything yet.)
• notmuch autocrypt account get <email> to get all data associated with a given account. This can also be used to get specific properties, such as notmuch autocrypt account get <email> enabled or notmuch autocrypt account get <email> secret_key.
• notmuch autocrypt peer get <email> to get a specific row from the peer table (implemented as a notmuch query with some postprocessing). This can similarly be used to get specific fields, such as notmuch autocrypt peer get <email> public_key.
• notmuch autocrypt recommend <account> [account]... to get a recommendation on whether or not to encrypt a given message to one or more peer accounts with autocrypt.

Unfortunately, there is no concept of a first seen date for messages without date headers in notmuch yet, but I believe this is being worked on. Consequently, my implementation always uses Date fields or ignores the message entirely. There is also some inefficiency in locating the most recent email of a given peer that contains a valid autocrypt header (or any autocrypt header for that matter; I am pretty sure my implementation fails for invalid autocrypt headers). Currently, I am looping through all of the peer's messages until I find one. This could be solved if notmuch new added an autocrypt tag, similar to how it adds an attachment tag to some messages, for instance.

• it may be of interest to display an indication of Autocrypt: headers on messages you have received

This could possibly be solved by adding an autocrypt tag as well.

Note: This is just a primer, of course, since there is not stable implementation of any kind of notmuch autocrypt command yet (at least to my knowledge). For now, those are just a few thoughts on how this functionality could be handled on the backend side so that we can think about whether we like it from the frontend perspective.