@Yujiri is this protocol meant to be used over plain TCP, or over TLS? is MITM part of the threat model?
decentralized
This is a community for the discussion and news about the decentralized web, software, privacy, and related topics.
Rules: be a good human being
Oh, hi. First you should know this post is old and the protocol has been drastically reimagined since. It's now a federated thing, combining inspiration from email, SMS, and Signal.
To answer your question, though: TLS isn't currently meant to be involved as I don't want to have two separate crypto systems floating around (which require 2 different crypto libraries as dependencies) and feel that TLS is not suitable due to how many irrelevant aspects it contains (metadata and signatures on certificates, trust chains, etc). All messages are end-to-end encrypted and users are identified by public keys so there's no way for a MITM to actually compromise message content. It is possible to MITM someone's connection to a homeserver. Things the attacker could achieve with this:
- Preventing your messages from being delivered (by inserting themself as the recipient's homeserver), and making you falsely think they have been delivered
- Preventing you from receiving messages sent to you, by inserting themself as your homeserver, and downloading your messages and discarding them.
- Learning the number of messages sent to you and when.
The reason I haven't bothered to try to prevent these is because I think the given that the attacker is able to MITM your connection makes them more or less inevitable. Consider: an attacker could also achieve #1 by just taking down the recipient's homeserver (eg. via DDOS) or your ISP, etc. (Caveat: the attacker wouldn't be able to fool you into thinking the messages were being delivered, but I don't consider that important.) They could do #2 and #3 by simply compromising your homeserver. In fact, they could probably achieve #3 by just being one of the routers between you and your homeserver and analyzing traffic statistics.
Really securing the connection between client and server would require some way of knowing what the server's key is supposed to be, such as certificate authorities or DNS records, neither of which are really secure systems. TOFU seems the most promising possibility. We might end up adding that to the protocol.