I just found out about Web Key Directory, maybe Delta Chat could use that as a method of key discovery in addition to Autocrypt? It can’t replace Autocrypt since WKD needs to be implemented server side whereas Autocrypt adds e2e to any mail server.
This other thread is super relevant and a prereq to this one.
Since more and more of my contacts are on WKD and not on autocrypt, I’ve found myself using Delta Chat less and less, more as a biff like app. I can read their messages in Delta Chat, but to send encryptedly to them I need to start the other MUA. And I need to try to remember which is which
It’s all because Proton implemented WKD. I’ve never used Proton but ever since I set up WKD on my email, all my messages from them have been encrypted, it’s just on by default (although Delta Chat doesn’t indicate that they are—there’s no padlock, and that’s for a pretty good reason since if I replied to them from Delta Chat itself, my replies to them would not be encrypted. If I do reply from my other MUA, my replies to them do have the padlock in Delta Chat which is also correct).
Mailvelope can also use WKD when sending if I understand it correctly.
Sandra, thanks for your always honest feedback – let’s see what we can do …
First a bit of my background on this. Personally, i’ve always found WKD an interesting concept – even talked about it at the first and only openpgp conference in 2016 and saw it as the future. Around the time several MUA developers got together (enigmail, K9 Mail, delta chat, debian gpg maintainer, mailpile and more) and determined a decentralized MUA-app driven way to distribute key and worked for some hundred hours specifying and implementing https://autocrypt.org in various e-mail apps. From 2018 TB with enigmail was nicely compatible with Delta Chat and also with K-9 mail. On some mailing lists it was suddenly possible to mail many of the subscribers with encrypted mail, directly. However, the TB core team then in 2019 “integrated” enigmail and, against the enigmail’s author and other’s recommendations, struck autocrypt support so that from 2020 on the overall encrypted e-mail situation fragmented again as TB is a heavy weight. Meanwhile mutt (a popular terminal based e-mail client), Fair-Email and Letterbox and others added seemless Autocrypt support.
We are currently working on making Delta Chat work more seamlessly with the way Thunderbird now handles encrypted e-mail.
For Delta Chat to integrate WKD lookups, we would need to integrate it with Autocrypt logic and also with our COUNTERMITM verified group protocols. Autocrypt works across providers and works quite seamlessly. Apart from multi-device setups there rarely are e-mail encryption problems between Delta Chat users. There is the “first message unencrypted” problem but, frankly, it’s not a foremost issue for people who are facing violent repression. However, we want to improve the UX situation there as well, and also add “degradation” warnings if encryption used to work but doesn’t anymore.
But back to WKD. Could you maybe help and provide more details on which MUAs and which providers currently support WKD, maybe also with links to blog posts/documentation? We’ll then discuss and see how DC could support it.
Ah, I know about Autocrypt—I helped work on the autocrypt function for notmuch-emacs.
I don’t have a complete-complete list, but the big one is Proton, who have come out against autocrypt in statements. So if we wanna work with them, WKD is the only route.
Their imap bridge also seems to support WKD in both directions, meaning that no matter what MUA they use, it automatically encrypts to me (and decrypts from me but that’s not because of WKD, that’s just the interface they’ve had to PGP all along).
So I’ve found that the typical Proton user is one who’s clueless* about encryption (or they’d just run their own PGP setup instead of paying 10€ per month for Proton) but also affirmedly want their emails encrypted so encrypting to them is never a mistake and now all their emails to me are automatically encrypted (even though I don’t use Proton at all and never have). It’s been a wonderful boon. It feels awful trying to adapt to their choices after their team was slagging Autocrypt on Reddit (or wherever it was) but ultimately our common goal is to make email better.
*: That’s not a slag on people who are clueless on tech, that’s my dream. I often feel like going down the rabbit hole of computer nerdery was a huge mistake.
I’ve also heard that Mailvelope supports it but I’m not sure to what extent that’s true since it can’t possible support key provision (since gmail users can’t supply WKD keys), only key retrieval. (That’s also what I suggest for Delta Chat—supporting WKD key retrieval)
GPG supports WKD key retrieval. That’s how I use it currently. I manually gpg --locate-keys the.persons.email@address.goes.here
for everyone I wanna send encryptedly to and then my other MUA sends encryptedly to them.
One idea I just thought of is that Delta Chat can also check our own email and see if we have WKD and if so, ask the user if they wanna import keys or export Delta Chat’s key to WKD and also use the results of the check to see how we wanna interact with other WKD addresses.
- WKD beats Autocrypt on MITM
- Autocrypt beats WKD on provider agnosticity
- Neither provides forward secrecy the way OMEMO / OTR does
I guess that this is because they are not signed. DC only shows a padlock if messages are encrypted and signed.
That’s wrong, they’re signed. No autocrypt headers but they’re signed.
Ah, probably then it’s because it’s not signed with ‘the sender’s key’ - there’s no Autocrypt header, so DC doesn’t know the sender’s key, so DC doesn’t can’t check the signature.
Is there a standard for doing that automatically or would it be a manual process for the user?
Not necessarily if your provider is the evil MITM actor, or if it is compromised?
Governments can block DNS entries, so it’s not a far fetch that they could modify them too to add redirections for people using their ISP’s dns server (most people, because that’s the default)
Not necessarily if your provider is the evil MITM actor, or if it is compromised
With DKIM they need to modify both DNS + headers whereas with autocrypt they only need to modify headers. Even though DNS is much easier to mod than mail headers, “easy+hard” is still harder than just “hard”.
Neither approach is MitM-proof but autocrypt is more susceptible than WKD.