Request for Consideration: Autocrypt at the message store

[mdecimus]

Hi,

I am the lead developer of the Stalwart open-source mail server and I've recently implemented an automatic encryption-at-rest feature, which uses either OpenPGP or S/MIME. This feature secures all incoming plain-text emails by automatically encrypting them before they're stored in the mailbox. Here is a link to the documentation in case you want to see how it was implemented.

As a strong proponent of user-friendly encryption, I find the Autocrypt specification aligns closely with the project goal of making secure communication accessible to everyone. I believe that extending the Autocrypt specification to support automatic encryption at rest could benefit the wider community.

I'd be interested to hear your thoughts on this. Is there room within the Autocrypt project to expand the specification to handle automatic encryption on the mail store side? And how would you envision managing Autocrypt headers in this scenario?

Thank you and I look forward to hearing your thoughts on this.

[hpk42]

Hi Mauro -- congrats to the new mail server implementation, quite interesting :)

not sure if there currently is sufficient dynamics to go for autocrypt spec updates soon but FWIW i am happy to offer my thoughts what it would take to implement encryption at rest using AC header information.

Users of your mailserver are authenticated and any added AC header in outgoing mails is a pretty strong signal (compared to incoming AC headers). So you could scan and store AC keys for your users from their outgoing mails and at best also memorize the prefer-encryption option.
If prefer-encryption is "yes" and there is a recent AC key for an e-mail address controlled by the server, and the last outgoing message(s) contained this AC key, then incoming messages could be encrypted to it.

However, autocrypt mandates that any message for it to be considered e2e-encrypted must also be signed -- and this you can't do because the incoming message was not signed/encrypted (if it was, you wouldn't need to do anything). Encrypting without signing would still be a net win for your users but i am not sure how MUAs react -- i believe Delta would be fine with it but would not show the message with a padlock (which is ok, it's not e2e-encrypted after all).

FYI https://github.com/deltachat/deltachat-core-rust/blob/master/src/peerstate.rs contains DC's AC-handling (using rpgp, a rust-pgp impl) but it's slightly more complex than what you need: you do not need to care for "gossip" or other incoming message handling regarding keys. If need be it could be possible to factor out any common code into an own crate but let's not start discussing that before you did an experimental mail-server AC-handling integration i'd say (whenever you get to it).

would be very curious about this and definitely want to look more into your mail-server efforts! cheers holger

On Wed, Aug 02, 2023 at 11:08 -0700, Mauro D. wrote:

Hi,

I am the lead developer of the Stalwart open-source mail server and I've recently implemented an automatic encryption-at-rest feature, which uses either OpenPGP or S/MIME. This feature secures all incoming plain-text emails by automatically encrypting them before they're stored in the mailbox. Here is a link to the documentation in case you want to see how it was implemented.

As a strong proponent of user-friendly encryption, I find the Autocrypt specification aligns closely with the project goal of making secure communication accessible to everyone. I believe that extending the Autocrypt specification to support automatic encryption at rest could benefit the wider community.

I'd be interested to hear your thoughts on this. Is there room within the Autocrypt project to expand the specification to handle automatic encryption on the mail store side? And how would you envision managing Autocrypt headers in this scenario?

Thank you and I look forward to hearing your thoughts on this.

-- Reply to this email directly or view it on GitHub: https://github.com/autocrypt/autocrypt/issues/447 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[mdecimus]

Hi Holger,

Users of your mailserver are authenticated and any added AC header in outgoing mails is a pretty strong signal (compared to incoming AC headers). So you could scan and store AC keys for your users from their outgoing mails and at best also memorize the prefer-encryption option. If prefer-encryption is "yes" and there is a recent AC key for an e-mail address controlled by the server, and the last outgoing message(s) contained this AC key, then incoming messages could be encrypted to it.

This is a good idea, I'll add it to the roadmap. Currently users have to manually upload their public keys using a web interface in order to enable automatic encryption. However, even if users have prefer-encryption set to yes and their public keys are obtained from the message, I still think it is a good idea to have them manually enable automatic encryption. In my opinion people need to be aware of automatic encryption at rest and give consent to it.

However, autocrypt mandates that any message for it to be considered e2e-encrypted must also be signed -- and this you can't do because the incoming message was not signed/encrypted (if it was, you wouldn't need to do anything). Encrypting without signing would still be a net win for your users but i am not sure how MUAs react -- i believe Delta would be fine with it but would not show the message with a padlock (which is ok, it's not e2e-encrypted after all).

That is correct, it is not signed but on both Thunderbird and Apple Mail the messages are shown with a padlock. This is the case for both OpenPGP and S/MIME.

If need be it could be possible to factor out any common code into an own crate but let's not start discussing that before you did an experimental mail-server AC-handling integration i'd say (whenever you get to it).

Sure, I'll look into that. Handling the AC signature should be fairly easy to implement having some Rust code as a reference.

would be very curious about this and definitely want to look more into your mail-server efforts!

Thanks! I also have plans in the future to implement a JMAP web client which will have full AC support.

Cheers, Mauro

[hpk42]

On Thu, Aug 03, 2023 at 10:10 -0700, Mauro D. wrote:

This is a good idea, I'll add it to the roadmap. Currently users have to manually upload their public keys using a web interface in order to enable automatic encryption. However, even if users have prefer-encryption set to yes and their public keys are obtained from the message, I still think it is a good idea to have them manually enable automatic encryption. In my opinion people need to be aware of automatic encryption at rest and give consent to it.

Sure, giving users a choice about at-rest encryption might be prudent. btw, could you send me (at my holger at deltachat de address) maybe test account credentials?

However, autocrypt mandates that any message for it to be considered e2e-encrypted must also be signed -- and this you can't do because the incoming message was not signed/encrypted (if it was, you wouldn't need to do anything). Encrypting without signing would still be a net win for your users but i am not sure how MUAs react -- i believe Delta would be fine with it but would not show the message with a padlock (which is ok, it's not e2e-encrypted after all).

That is correct, it is not signed but on both Thunderbird and Apple Mail the messages are shown with a padlock. This is the case for both OpenPGP and S/MIME.

It's questionable to show a padlock if the message was not signed precisely because of the implementation we are discussing here -- an at-rest encrypted messages are not end-to-end encrypted. See also https://autocrypt.org/level1.html#message-encryption

If need be it could be possible to factor out any common code into an own crate but let's not start discussing that before you did an experimental mail-server AC-handling integration i'd say (whenever you get to it).

Sure, I'll look into that. Handling the AC signature should be fairly easy to implement having some Rust code as a reference.

would be very curious about this and definitely want to look more into your mail-server efforts!

Thanks! I also have plans in the future to implement a JMAP web client which will have full AC support.

JMAP is not that interesting for e2e encrypting mail clients but would be curious about your rationale for it and which e-mail apps support JMAP.

[mdecimus]

Sure, giving users a choice about at-rest encryption might be prudent. btw, could you send me (at my holger at deltachat de address) maybe test account credentials?

It is a self-hosted solution only at the moment and I haven't had a chance to deploy a test/demo server yet. If you have a few minutes you can check it out using the Docker image.

It's questionable to show a padlock if the message was not signed precisely because of the implementation we are discussing here -- an at-rest encrypted messages are not end-to-end encrypted. See also https://autocrypt.org/level1.html#message-encryption

I don't think Apple Mail implements Autocrypt but Thunderbird does and they show the padlock with a green tick when the message was encrypted (but not signed) by the mail server. When clicking on the padlock, they do include a small warning about the message not being signed but they also say it is mostly safe to ignore this warning.

JMAP is not that interesting for e2e encrypting mail clients but would be curious about your rationale for it and which e-mail apps support JMAP.

There is already a JMAP extension for S/MIME signing and encryption that should be published soon. Not sure if you have checked the JMAP Mail specification before but it is basically a more powerful IMAP4 with Email Submission capabilities, so it is perfectly possible to implement autocrypt on a JMAP client.

[dkg]

fwiw, doing autocrypt at the MTA (the "message store", as it's framed here) is similar to the proxy pattern described in draft-ietf-lamps-e2e-mail-guidance as a "dangerous choice".