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.
1 Like
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
1 Like
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.
1 Like
The current model of Chatmail, the preferred way of using Deltachat, is to prevent all outgoing emails that are not encrypted and to use that as an anti spambot measure (in the sense that spambots have no interest opening a chatmail account). The only way this works is if the public key is somehow secret: having an email address isn’t enough, you need the PGP key to actually talk to that person. DC gives a way to automatically share both the email and the key to start the securejoin protocol, which is MITM-safe, and is the preferred way to add contacts. The consequence is that this model favors small communities of people who either already know each other or are face-to-face.
WKD is the old-style email model: once they know the address, anybody can send anything to you. If there’s a key, WKD gives it to the sender no questions asked. This model is the “anyone can talk to anyone on the internet”
I think the introduction of WKD means a change in the model that is different enough to warrant a discussion focused more on the social aspects than the technical aspects. Allowing incoming WKD (ie chatmail offering a WKD endpoint) would render the anti spambot useless, but allowing outgoing WKD (ie DC fetching WKD keys) would make interoperability better without proper guarantees at a secure channel between correspondents
1 Like
I use Delta Chat with Postfix and Dovecot. The normal way. To message all kinds of people even those that don’t use PGP. That’s like half of the people I have on here.
That needs to keep working. This whole “chatmail server” thing is completely wack. The entire USP of Delta Chat over XMPP/OMEMO is to be able to message normal people’s normal email address.
Now, what I want is to be able to import public PGP keys to my contacts. A lot of people use PGP without autocrypt. I can manually fetch them from WKD. If Delta Chat down the line adds WKD support directly, that would be awesome, but that’d be gravy on top of what I really want which is to send PGP email to non-autocrypt peeps.
Which in turn is gravy on top of being able to send normal email to normal people. That is the base level of functionality in an email app. If that’s no longer “the preferred way”, that sounds like a bad dream. I’m absolutely not onboard with that. Delta Chat would become a much worse version of XMPP/OMEMO if it couldn’t even send normal email.
3 Likes
Support for unencrypted emails and profiles using non-chatmail servers are not going to be dropped. Rough idea currently is to have unencrypted contacts (identified by the email address) and PGP-contacts (identified by the OpenPGP-fingerprint), so it will then be possible to import the key (or vCard) and have at least 1:1 chat with such contact that does not implement Autocrypt.
1 Like
I just realized today that since the only drawback of the wonderful wonderful WKD is that it needs serverside support… chatmail could add it! Since it’s already it’s own server. And then become compatible with Proton and others. The install base of encrypted mail would join like two amöbae on acid! WKD lookup is something I’ve dreamed of before already so here’s one more reason to.
But speaking of chatmail. I had a bad experience with a chatmail user today (I was on vanilla postfix/dovecot, not chatmail) because it has the “first message problem”. With normal autocrypt you can send one message and from then on you’re off to the races and it’ll be encrypted from then on. (WKD doesn’t need this, it can be encrypted right away.) But since chatmail can’t send unencrypted you can’t really bootstrap the convo! Except for some weird Delta Chat-specific link! We also tested that I sent an unencrypted-but-with-autocrypt-headers email to him and that did not get through either, it bounced with a 523 Encryption Needed: Invalid Unencrypted Mail. Conclusion: chatmail has a vendor lock-in problem! 
I would’ve wanted Delta Chat to move in the direction of increased compatibility with the wider email/PGP world, not away from it 
Of course it’s convenient, but everything convenient comes at the cost of privacy. Besides, lately we’re trying to hang too much onto a regular mail relay. I believe Autocrypt has its own advantages — and they lie in security.
The hoops me and my chatmail-using friend had to go to to start
chatting (because of the “first message problem” that chatmail
has) involved an URL across Delta Chat’s servers so not super
privacy friendly there.
And the notion that WKD would cost more privacy than Autocrypt
doesn’t make any sense at all. Autocrypt isn’t more secure than
WKD in any way. Autocrypt’s only advantage is that it works with
any mail server like Gmail and Hotmail (although the latter now
is incompatible with Delta Chat).
So even before Chatmail I was wishing and hoping for WKD lookup
in Delta Chat as another way to get PGP keys. But now with the
push towards Chatmail (that I’m glad will remain optional and
that support for normal email, for chatting with the grandparents
over normal TLS s2se email, will remain), WKD could be served up
so the lookup could go both ways for compatibility with the
entire Proton userbase. Posteo already has both Autocrypt and
WKD.
We all know that Thunderbird tragically (and arguably through
deliberate cruelty) dropped the ball on automatic e2ee in a way
that collaterally affected both Enigmail and K-9 but we don’t
need to follow their descent into sadness but could instead
embrace the wider PGP community!
1 Like
I understand that there are some issues with encryption and auto-configuration in classical email. But we’re talking about security, and for security, it’s best to use a chat mail relay without any problems or failures. I don’t consider sending the first message to establish encryption between correspondents a problem, and I prefer that approach over storing users’ public keys on the server, even though that would indeed make it more convenient to send initially encrypted files to a recipient’s public key if they are offline. In DC, this is currently possible — if you share a contact with someone, the .vcf file includes both the image in base64 and the public key, which makes it possible to send encrypted messages right away, even if the recipient is offline.
On top of all this, I’d add that it’s possible to create a service for storing .vcf files, similar to how it’s done on keys.openpgp.org, but more modern. For example, it could work through the same bot in DeltaChat.