4 ms·

I think Conversations is probably getting a lot right, but you also mention its biggest flaw: > do multiple types of encryption including OTR and OMEMO Oh and

by hannob 10y ago

I think Conversations is probably getting a lot right, but you also mention its biggest flaw: > do multiple types of encryption including OTR and OMEMO Oh and it can also do something else: no encryption at all. That's the problem with XMPP: The user is faced with three different encryption modes, none of them is the default. There shouldn't be multiple types of optional encryption. There should be one that works and is enabled by default.

majewsky 10y ago
The practical problem is that a lot of power-users have strong opinions about which e2e scheme to use in which case. That may include "none". [1] If you enforce a single e2e scheme (no matter which), you will lose a lot of potential power-users, who would double as multipliers to spread your app. I don't say that Conversations (and the XMPP community at large) couldn't do better, though. For example, there could be a standardized, automated, transparent process for determining which e2e schemes are supported by the clients involved in the conversation. [1] For example, I skip e2e when talking to my several XMPP bots. They run on the same host as the XMPP server, so e2e won't reduce my attack surface when I already have TLS enforced along the way, but make the bot implementation considerably more complex.
- Drdrdrq 10y ago
  > you will lose a lot of potential power-users, who would double as multipliers to spread your app. Not really. I consider myself poweruser in many areas, but I would never recommend most of my tools to "ordinary" friends. The tools for them should be easy to use and difficult to misuse.
upofadown 10y ago
In practice you always get TLS. That's really all you need if you trust the server. Something fairly significant has happened in the world of XMPP recently. You can get real certificates for XMPP servers under your control from letsencrypt. That means that things now work transparently between clients and servers and between servers. As a result, organizations that do things that some governments might not approve of can do transparent encryption simply by setting up a server or servers in places that such governments can not physically get at.
- hannob 10y ago
  TLS on the s2s side is unauthenticated. Therefore TLS only protects you in a situation where both users are on the same server and trust it. Getting a real cert for s2s doesn't really help as long as you have no agreed upon mechanism how they can enforce validation of those certs.
  - upofadown 10y ago
    You need to trust both servers when doing s2s anyway. So you can just turn on certificate validation when depending on just TLS for your security. For Prosody that would be "s2s_secure_auth = true". Of course an organization using TLS as their only security for XMPP would almost for sure just use one secure server, so I might be being a bit fanciful here. My ultimate point is that because of the way XMPP works, it is possible to make the normal default clients work securely in practice by doing the correct things at the server level.

by hannob 10y ago

majewsky 10y ago

The practical problem is that a lot of power-users have strong opinions about which e2e scheme to use in which case. That may include "none". [1] If you enforce a single e2e scheme (no matter which), you will lose a lot of potential power-users, who would double as multipliers to spread your app. I don't say that Conversations (and the XMPP community at large) couldn't do better, though. For example, there could be a standardized, automated, transparent process for determining which e2e schemes are supported by the clients involved in the conversation. [1] For example, I skip e2e when talking to my several XMPP bots. They run on the same host as the XMPP server, so e2e won't reduce my attack surface when I already have TLS enforced along the way, but make the bot implementation considerably more complex.

Drdrdrq 10y ago
> you will lose a lot of potential power-users, who would double as multipliers to spread your app. Not really. I consider myself poweruser in many areas, but I would never recommend most of my tools to "ordinary" friends. The tools for them should be easy to use and difficult to misuse.

upofadown 10y ago

In practice you always get TLS. That's really all you need if you trust the server. Something fairly significant has happened in the world of XMPP recently. You can get real certificates for XMPP servers under your control from letsencrypt. That means that things now work transparently between clients and servers and between servers. As a result, organizations that do things that some governments might not approve of can do transparent encryption simply by setting up a server or servers in places that such governments can not physically get at.

hannob 10y ago
TLS on the s2s side is unauthenticated. Therefore TLS only protects you in a situation where both users are on the same server and trust it. Getting a real cert for s2s doesn't really help as long as you have no agreed upon mechanism how they can enforce validation of those certs.
- upofadown 10y ago
  You need to trust both servers when doing s2s anyway. So you can just turn on certificate validation when depending on just TLS for your security. For Prosody that would be "s2s_secure_auth = true". Of course an organization using TLS as their only security for XMPP would almost for sure just use one secure server, so I might be being a bit fanciful here. My ultimate point is that because of the way XMPP works, it is possible to make the normal default clients work securely in practice by doing the correct things at the server level.