3 ms·

> It supports S/MIME. Do you want S/MIME? (You don't.) Could you provide your source? I've never seen S/MIME used in XMPP. Client certificates for authenticati

by Boulth 8y ago

> It supports S/MIME. Do you want S/MIME? (You don't.) Could you provide your source? I've never seen S/MIME used in XMPP. Client certificates for authentication sure but not for E2E security. > It supports OTR, TS and SCIMP too: but you need to be an expert in messaging schemes to understand how those are different. OTR is being rolled back from clients in favor of OMEMO for good reasons: https://conversations.im/omemo/ https://conversations.im/omemo/

lvh 8y ago
S/MIME for XMPP E2E: https://xmpp.org/rfcs/rfc3923.html https://xmpp.org/rfcs/rfc3923.html I am aware that OTR is being rolled back. My point is that extensibility is at odds with practical security and privacy for the vast majority of users. The people who need it the most do not understand the difference between OMEMO and OTR, but I can tell them to go install WhatsApp or Signal, give them a rough idea of why you want one or the other, and everything will be copacetic.
- Boulth 8y ago
  Thanks for the link, it appears to be from 2004. > The people who need it the most do not understand the difference between OMEMO and OTR, For most of them there won't be any difference. Modern clients do not implement OTR so people will not even encounter the term and OMEMO is enabled by default so users don't need to bother with it. Federated protocols can be made secure, if there are popular, secure by default players on the market. Look at what happened with HTTP2 and TLS 1.3: browsers basically used their powerful position to upgrade the security for the entire federated ecosystem. There are also other minor factors, such as tooling (SSL Labs) that incentivizes people to maintain their servers. And most certainly users of HTTPS don't need to understand how e.g. Certificate Transparency works, that's handled internally by their clients (browsers). Of course there will always be a niche of low security clients, but who cares that TLS 1.2 doesn't work on some old Java?
  - lvh 8y ago
    In what sense is HTTP/2 or TLS 1.3 federated?
    - Boulth 8y ago
      HTTP/2 is federated in a sense that the network is composed out of heterogeneous nodes operated by different parties and these nodes communicate with each other (applications running on servers frequently act as clients accessing other HTTP servers). If calling HTTP/2 federated bothers you I can rephrase my argument: > Federated protocols can be made secure, if there are popular, secure by default players on the market. Look at what happened with the other IETF-standard protocol: HTTP2: browsers basically used their powerful position to upgrade the security for the entire ecosystem. There are also other minor factors, such as tooling (SSL Labs) that incentivizes people to maintain their servers. And most certainly users of HTTPS don't need to understand how e.g. Certificate Transparency works, that's handled internally by their clients (browsers).
- SamWhited 8y ago
  This isn't actually a thing anyone uses; I'm not aware of any non-commercial XMPP clients implementing it. It's just an attempt the IETF had a while back at standardizing E2E. It didn't really work, OMEMO has come much further. And you don't have to explain the difference between OTR and OMEMO to anyone, just tell them to "Go use Conversations, it's on the Google Play store" and they'll be using OMEMO to speak with you.

by Boulth 8y ago

lvh 8y ago

S/MIME for XMPP E2E: https://xmpp.org/rfcs/rfc3923.html https://xmpp.org/rfcs/rfc3923.html I am aware that OTR is being rolled back. My point is that extensibility is at odds with practical security and privacy for the vast majority of users. The people who need it the most do not understand the difference between OMEMO and OTR, but I can tell them to go install WhatsApp or Signal, give them a rough idea of why you want one or the other, and everything will be copacetic.

Boulth 8y ago
Thanks for the link, it appears to be from 2004. > The people who need it the most do not understand the difference between OMEMO and OTR, For most of them there won't be any difference. Modern clients do not implement OTR so people will not even encounter the term and OMEMO is enabled by default so users don't need to bother with it. Federated protocols can be made secure, if there are popular, secure by default players on the market. Look at what happened with HTTP2 and TLS 1.3: browsers basically used their powerful position to upgrade the security for the entire federated ecosystem. There are also other minor factors, such as tooling (SSL Labs) that incentivizes people to maintain their servers. And most certainly users of HTTPS don't need to understand how e.g. Certificate Transparency works, that's handled internally by their clients (browsers). Of course there will always be a niche of low security clients, but who cares that TLS 1.2 doesn't work on some old Java?
- lvh 8y ago
  In what sense is HTTP/2 or TLS 1.3 federated?
  - Boulth 8y ago
    HTTP/2 is federated in a sense that the network is composed out of heterogeneous nodes operated by different parties and these nodes communicate with each other (applications running on servers frequently act as clients accessing other HTTP servers). If calling HTTP/2 federated bothers you I can rephrase my argument: > Federated protocols can be made secure, if there are popular, secure by default players on the market. Look at what happened with the other IETF-standard protocol: HTTP2: browsers basically used their powerful position to upgrade the security for the entire ecosystem. There are also other minor factors, such as tooling (SSL Labs) that incentivizes people to maintain their servers. And most certainly users of HTTPS don't need to understand how e.g. Certificate Transparency works, that's handled internally by their clients (browsers).
SamWhited 8y ago
This isn't actually a thing anyone uses; I'm not aware of any non-commercial XMPP clients implementing it. It's just an attempt the IETF had a while back at standardizing E2E. It didn't really work, OMEMO has come much further. And you don't have to explain the difference between OTR and OMEMO to anyone, just tell them to "Go use Conversations, it's on the Google Play store" and they'll be using OMEMO to speak with you.