with Delta Chat’s invite links there is warrantied e2e encryption without MITM, and encryption can never drop or change in Delta Chat since v2, if someone write from a different encryption key, it will appear as a totally different/new contact request, so even if the email server tries to fake messages from a contact using a new key, they can’t take over the contact’s chat
using classic email to send unencrypted email and wait that the reply upgrades to encryption have the MITM problem and it is good we moved away from that approach, it was a plain vulnerability an source of criticism, what we have today might not be the easiest way to get on contact on earth but is a pretty good compromise between security, usability and independence of a central server
There are others who have made a similar point. In fact there is a discussion about this here:
Delta Chat developers often take design cues from other popular messaging apps like Signal and implement features from other apps at their discretion, so it’s reasonable to point to what other apps are doing while discussing the pros and cons of that approach.
It’s clear that there are situations where an “easily remembered username” could be very useful, and since we know there are some security drawbacks to that approach, perhaps that discussion can take place in the wider context of trust design.
This is good to know. I think there is an opportunity here to improve and update the onboarding sections of the FAQ so people in Sandra’s situation are aware of all their options. I just took a look at the help section here and it doesn’t mention at all that you can use other clients to open the invite links. And there is another section of the FAQ which still says “If you create a chat profile with a classic e-mail address you may manually create a contact if you know their e-mail address”, but that’s no longer true if your contact uses chatmail.
There will always be ignorant people. We shouldn’t let their opinions affect us.
This makes sense due to the ease of instant onboarding and the added convenience like support for Apple/FCM push notifications.
Thanks for replying. I understand that Delta Chat’s current approach using SecureJoin with guaranteed E2EE prevetns MITM.
I understand that the old approach with Autocrypt has a MITM problem, but I assumed that was due to TOFU not TOEU like Sandra said and I am trying to understand why in that case it would be trust on every use instead of trust on first use. I’m just trying to understand this to have better knowledge about Autocrypt, even if Delta Chat doesn’t use it any more.
This is only true if the invite link isn’t intercepted and possibly altered. That is why the current always trusted never expiring invite link design bothers me a little.
Autocrypt includes public keys in its headers in each e-mail. If the keys change the change is expected to be silently accepted.
This is TOEU, and obviously it is fairly rubbish security, and obviously the designers knew this. The idea of Autocrypt was a universal encryption standard that never broke anything. Autocrypt level one is only intended to protect against passive adversaries where there is no risk of the encryption breaking anything. The idea is to make level one really easy to adopt, then gradually ratchet up the security level in subsequent versions. See: Autocrypt Level 1: Enabling encryption, avoiding annoyances — Autocrypt 1.1.0 documentation
Deltachat does not allow the lower-security aspects of the Autocrypt standard. All Chatmail messages (incoming or outgoing) must have Autocrypt headers or the Chatmail servers will reject them. And when you add a new contact, the Deltachat client reads the headers and checks that the header key matches the fingerprint in the QR code or invite link. But if the header key changes, the message is dropped. This is not TOEU. It isn’t even TOFU; if the header key did not match the invite link, the message would also be dropped.
I came to Deltachat because I was looking for an e-mail client (for mobile Linux, encryption-capable). To me, the biggest selling point of Deltachat is actually compliance with open standards and interoperability.
Ease-of-use is second (there are lots of easy-to-use proprietary systems). Deltachat means I can swap encrypted mails with people who do not know what an encryption key is.
The chat format is a mild downside to me: it discourages long-form letters and encourages short chat messages. Which is fine, but I like long-form letters, so I’m not using DC for a lot of mails, especially if my correspondant does know what an encryption key is . Many mailclients also now have more chatlike threaded views.
I think Deltachat could absorb the e-mail community if it had a client with a more traditional UI:
I also suspect that a traditional mailclient implementing free Chatmail accouts, plus SecureJoin and/or WKD, would see a strong increase in popularity. Though the entire DC backend offers much more than just that!
Incidentally, it looks as though Autocrypt may by returning to Thunderbird as an extension. Thunderbird is popular, and the more popular a client is, the more important standards-compliance and compatibility become.
This is unmaintained and is not compatible with Thunderbird. Maybe works with SeaMonkey, but definitely not with the latest Thunderbird that has native OpenPGP support.
I did not know about Public Key Bot. That’s really useful, actually. A TOFU bot would presumably also be possible; I think it’s basically the same as a public invitation bot. Posting a QR code publicly is also TOFU.
manually exchanging key files (.asc or VCard) or QR codes or invite links 6a. including downloading them from keyservers and sending them in plaintext, even over horribly insecure networks
Six is moderately easy but not obvious in the UI.
It makes sense to favour the method that is easiest to do securely, and steer users to it. There are those who need another method, usually because they can’t physically meet friends, but they seem to be a minority. We could think about what the UI should steer them to (since I think “screenshot my QR and send it, often insecurely” is the current default).
Other methods are not hard to do, but not obvious in the UI. They require that the user understand them.
I agree that DC shouldn’t replace a classic email client, but it makes sense to allow reasonable communication with non-DC contacts within a chat interface. At least as long as there is technical compatibility with email.
In my opinion, only two changes are necessary to achieve this goal:
The ability to change the subject WITHIN a 1:1 chat. As it is now, it quickly becomes very confusing. A while ago, I made a suggestion on how this could be achieved without having to change the UI, because I consider it important that chats with non-DC contacts differ as little as possible from chats with DC-contacts. Otherwise, you might as well just use a traditional email client. Subject of emails - #110 by Raiden
Furthermore, I think that groups with non-DC contacts are superfluous. They often don’t work well in reality, as non-DC users quickly become confused. Even with normal email apps, I rarely send one email to multiple recipients and rarely receive such emails.
@pichsi, Adbenitez has made a lot of really useful contributions to the Deltachat ecosystem, and just a couple days ago was scolding me, quite reasonably, for perfectionism.
I wouldn’t worry about Deltachat dying. There are too many users, there are third-party apps, there are lots of people enthusiastic about it.
While I don’t see the case for Adbenitez’s chat-app/mailclient dichotomy, I’d assume that Adbenitez, who is much more familliar with the project than I am, has seen some tradeoffs that make him think this way. I’m worried about losing features I value, and never getting others which I would value. But I respect Adbenitez’s work and his judgement; even when I disagree with his ideas, understanding them is worthwhile.
Disagreement about software design among users is inevitable, and the devs can’t please everyone all the time. But we can choose how we deal with disagreement socially. Deltachat development will be improved if the developers and users can discuss their disagreements without emnity. No-one wants to work in a hostile environment. It is so easy for a forum post to come off more hostile than intended, as this thread amply and repeatedly demonstrates.
Do you have views on how WKD can or should be used in Deltachat? Can you tell us how you use or want to use it?
I think on reflection I’m happy with the current setup. It does have the advantage of hiding my IP address from the server. I think it needs better documentation, and will write a how-to post once I understand the other keysharing methods better (I started dafting one a while ago).
I can see the argument for integrating WKD into all mail clients; it is similar to the argument for Autocrypt. I don’t think DC should be an early adopter, tho; I want to retain the secret-public-keys system anyway, and the advantage of open standards is that we can wait and see how other mail clients handle whatever problems come up with WKD (Will encrypted spam become a problem, for instance? Will WKD give servers more metadata and users less privacy? Will there be MITM attacks, from the servers or DNS poisoning?).
Deltachat also has “You don’t need to trust the server” as a strong design principle, and if I get my keys from a hidden page at one unmirrored server (which is what happens, if I understand WKD correctly), then I really need to trust it! This could be especially problematic for users in authoritarian countries.
Yes, WKD is just anoher magic crutch which uses ‘Trust the server’ model.
If I own and trust the chatmail server, I can setup WKD on it to distribute my public key. But how other DC users that want to establish DC conversavion with me should know that I’m trusting this particular server to distribute my real key? There is no way, if they do not have my pubkey…
If one party is using webmail you are essentially trusting the server anyway. A webmail server is excellently placed to do a MITM attack. And WKD does avoid having to trust anything except the end servers, which are at least consciously chosen by the people.
So, like Autocrypt, WKD a step in the right direction, and later versions could add more security.
. Many mailclients also now have more chatlike threaded views.
the situation.