4 ms·

I have a suggestion for this and other projects like it: When you are establishing a standard that clients and servers will advertise that they adhere to, don'

by dsr_ 5y ago

I have a suggestion for this and other projects like it: When you are establishing a standard that clients and servers will advertise that they adhere to, don't leave technical decisions to the end-user by default. Make the best decision that you can. In this document, there's discussion about STARTTLS vs TLS-from-the-beginning, and how to deal with that in the UI. Don't do that. Decide that TLS-from-the-beginning is the requirement for client-server interactions, and now you don't have a UI issue. You already decided that /resource and priority were not going to be useful; make this decision too. In general, resolve incompatibilities.

ocdtrekkie 5y ago
Indeed. I think this stems from presumably wanting to support legacy XMPP where possible, email servers and FTP servers are the other two places this option often comes up. But it should probably be really clear that the correct way is X, and support for Y should be buried somewhere so most users don't have to think about it, if you do feel a need to retain support for it.
- MattJ100 5y ago
  Agreed! As in my sibling comment just now, I've updated this section to say basically that.
MattJ100 5y ago
You're completely right, thanks for the spotting that and the feedback! I was going to remove it, but I don't think that's the problem. The whole section you mention is the problem - all these options should be auto-discovered, and in fact are, in any normal deployment. It's sometimes used for unusual deployments (connecting over a VPN, or a testing/development server). For normal deployments, XMPP already defines which host/port/TLS-mode to use and how a client can pick between them. So I've just merged an update that clarifies that these options are not generally recommended for implementations to expose to users, except to support testing/development. I'd rather have this documented (i.e. "if you are going to do this anyway, at least do it correctly, like this").
- kbenson 5y ago
  > all these options should be auto-discovered, and in fact are, in any normal deployment. I think that's a slightly different thing than what was suggested. For some options, auto-discovery is fine. For security, I think the current consensus is just make the best choice you can, and if something really requires a major change, version the standard (major version, like from 1.x to 2.0, so it's obvious). Auto-discovery of a setting to do with security is just another possible location where a security issue might be found because or a poor implementation of the standard.
  - MattJ100 5y ago
    Sure, but I don't think that applies here. The section in question is about a settings screen where (for some reason) the user is manually entering all the connection parameters. There is no way to detect (without probing) whether the port that the user configured is using STARTTLS or direct TLS. Both are commonly deployed. Probing could be implemented, but that quickly introduces complexity (and code just as likely for security issues to hide in) to implementations. It would be nice to one day say "only support direct TLS" for example, but that's not the reality of today's network (looks like ~41% of servers advertise direct TLS as of today, slowly climbing). So the happy path is using auto-discovery as standardized. If you go the manual path and configure a host/port, I don't think probing is sensible to recommend, and I don't think strictly assuming only one or the other is going to fly right now.
    - deleted 5y ago
      [deleted]
    - kbenson 5y ago
      Is this just for clients, or for servers as well? If it's for servers also, I guess that's a question of what you want this to be then. Is it a descriptive document that says "this is what Modern XMPP looks like as we see it in the wold" or a prescriptive document that says "This is what you need to do to be a modern XMPP deployment so we can fix some problems of the past". Maybe one way that might look is user clients that probe, but when defining how servers should act, there's a "one true way" unless they aren't adhering to Modern XMPP spec or best practices. Changes like this need a push from outside or they never happen, and someone just being able to point at a spec and say "look, you aren't compliant with Modern XMPP, the world has moved on from what you're doing" is incredibly useful in spurring change. I agree it doesn't necessarily make sense for a client options perspective, but it might be a good principle to adopt or consider for other aspects of the document. If you want to actually push things forward, I think it's very useful way to do so.
Lammy 5y ago
> When you are establishing a standard that clients and servers will advertise that they adhere to, don't leave technical decisions to the end-user by default. On principle I agree, but ironically the exact scenario you suggest was the single biggest event that "killed" XMPP as we used to know it. In late 2013 there was an XMPP community manifesto calling for mandatory TLS (even STARTTLS) for XMPP server-to-server communication by a drop-dead date in early 2014: https://github.com/stpeter/manifesto/blob/master/manifesto.txt https://github.com/stpeter/manifesto/blob/master/manifesto.t... "The schedule we agree to is: - January 4, 2014: first test day requiring encryption - February 22, 2014: second test day - March 22, 2014: third test day - April 19, 2014: fourth test day - May 19, 2014: permanent upgrade to encrypted network, coinciding with Open Discussion Day <http://opendiscussionday.org/ http://opendiscussionday.org/>" Well-intentioned for sure, but the one XMPP provider with an actual critical mass of users (Google Talk) remained non-TLS-only, all Google Talk users dropped off the federated XMPP network after May 2014, and so XMPP effectively ceased to matter.
- MattJ100 5y ago
  In fairness, by 2014 it was fairly obvious that Google was no longer interested in furthering Google Talk. It was about the time that they were pushing folk to Google+ and Hangouts. Google's XMPP server continued to accept unencrypted connections for many years after this point. I think the XMPP operators made the right choice, rather than letting Google weaken the security of the entire network.
  - Lammy 5y ago
    > by 2014 it was fairly obvious that Google was no longer interested in furthering Google Talk Definitely, but I think it was a huge PR failure that we in the XMPP community were the ones to sever the conversational link. Users shouldn't be expected to think about the protocol details, hence this thread, and it was an XMPP community decision that resulted in people being suddenly unable to talk to their friends. We provided perfect justification for any Google project manager to look at the stats and see zero incoming s2s connections as justification to kill Talk entirely so they could Move Fast™ on Hangouts or whatever. I guarantee we pushed more overall XMPP users to WhatsApp/FB than we pushed Google Talk users to privacy-first XMPP hosts since it's not like Google popped up any alert in the GMail Talk UI explaining to people why their nerd friends all suddenly vanished from their buddy lists. The moment any of those people used a non-XMPP service to reach out and ask "What's up?" we had already lost :/
giancarlostoro 5y ago
Yeah, I would argue pick one secure way for the client to ask which one the server prefers and dont let the end-user even bother thinking about it.
- southerntofu 5y ago
  That's already what happens in practice, as defined in XEP-0368 SRV records for XMPP over TLS https://xmpp.org/extensions/xep-0368.html https://xmpp.org/extensions/xep-0368.html That UX description is intended for "additional connection options" prompts, which are useful when your server is misconfigured or you want to reach it in a different manner than advertized over DNS (eg. over a .onion address).
  - giancarlostoro 5y ago
    Oh I see, that makes sense then. I didn't realize Onion instances needed special customization, is there no way to fix this UX?
    - southerntofu 5y ago
      Great question! onion vhosts (user@foobar.onion addresses) don't need that, as long as your client can resolve onion addresses (Gajim/Conversations have good tor integration, otherwise Tor's AutomapHostsOnResolve will do the trick systemwide but in that case your client may complain that the domain doesn't support TLS or with a wrong certificate). "Advanced" connection settings is required when the vhost you are connecting to doesn't match the hostname you need to reach on the network. For example, if you're reaching your server over a VPN/SSH/IPSEC tunnel. Another example is if you wish to login as user@foobar.com by reaching foobar.onion. This is useful if you want to be part of the broader Jabber federation, in which not every host supports federation over onion addresses (i'd be curious to make stats about that) but it still gives you the security guarantees of Tor when reaching your server (though not for server-to-server connections). Onion name discovery for automatically upgrading to onion routing when Tor is available client-side is not yet specified within the XMPP ecosystem. Onion discovery in the HTTP ecosystem is usually done via Onion-Location HTTP header (HTTPS only), in the email ecosystem they use _onion-mx DNS SRV records: see https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt https://gitweb.torproject.org/tor-browser-spec.git/tree/prop... and https://github.com/ehloonion/onionmx/blob/master/SRV.md https://github.com/ehloonion/onionmx/blob/master/SRV.md respectively Implementing something similar XMPP side would be easy. Prosody already has a community mod_onions, but currently only supports a static map of hosts to their onion addresses. It could use some love: https://modules.prosody.im/mod_onions.html https://modules.prosody.im/mod_onions.html Another problem we face from a UX perspective for onion services is that currently XMPP server implementations are very strict about which node/resource messages are intended for, and to my knowledge none support aliasing systems as we have in the email world. In this specific example application of aliases, there's currently no way (that i know of) to have the same account across .org/.onion domains and having servers to know it's the same account in a federated manner, eg. to prevent you from adding the same person twice to your contact list. All in all there's interesting challenges and none of them is really hard so if you'd like to get involved or just let us know about your ideas and expectations, feel free to drop by xmpp:privacy@joinjabber.org?join
nashashmi 5y ago
I understand where this is coming from. But this kind of early decision making can hurt the growth and adoption of projects. Think of it as Apple making a bunch of decisions for themselves and their users and it keeping problematic for future adoption. The spirit of open source is voluntary participation and openness to all platforms and ideas. Though I cannot understand the distinction behind TLS and STARTTLS , I don’t think locking in one option will make it all that better.
- southerntofu 5y ago
  > Though I cannot understand the distinction behind TLS and STARTTLS , I don’t think locking in one option will make it all that better. StartTLS starts unencrypted then "upgrades" the connection to TLS if the client and server support it. This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless. That's not to say TLS is perfect: having to trust an entire list of third-party CAs with their own incentives/pressures is a flawed model. But TLS is better than no TLS, so direct TLS is better than StartTLS.
  - MattJ100 5y ago
    > This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless. This is a common misconception about STARTTLS. It is certainly possible to implement it poorly (and that has certainly happened). But there are no inherent security issues with a correct implementation. An active attacker can just as easily block TLS handshake packets on a direct TLS connection. The problem used to be that many software implementations (not just XMPP) would happily continue unencrypted if STARTTLS was not offered. But these days everyone requires TLS, and will not proceed to connect unless TLS is in use (regardless of whether it is negotiated or "direct"). However the future is certainly direct TLS, that has been obvious for some time. It has many advantages, such as allowing the use of off-the-shelf middleware such as loadbalancers and proxies, and bypassing certain firewalls. It's also easier to implement, and there is of course the (relatively new) ESNI which is beneficial.

by dsr_ 5y ago

ocdtrekkie 5y ago

Indeed. I think this stems from presumably wanting to support legacy XMPP where possible, email servers and FTP servers are the other two places this option often comes up. But it should probably be really clear that the correct way is X, and support for Y should be buried somewhere so most users don't have to think about it, if you do feel a need to retain support for it.

MattJ100 5y ago
Agreed! As in my sibling comment just now, I've updated this section to say basically that.

MattJ100 5y ago

You're completely right, thanks for the spotting that and the feedback! I was going to remove it, but I don't think that's the problem. The whole section you mention is the problem - all these options should be auto-discovered, and in fact are, in any normal deployment. It's sometimes used for unusual deployments (connecting over a VPN, or a testing/development server). For normal deployments, XMPP already defines which host/port/TLS-mode to use and how a client can pick between them. So I've just merged an update that clarifies that these options are not generally recommended for implementations to expose to users, except to support testing/development. I'd rather have this documented (i.e. "if you are going to do this anyway, at least do it correctly, like this").

kbenson 5y ago
> all these options should be auto-discovered, and in fact are, in any normal deployment. I think that's a slightly different thing than what was suggested. For some options, auto-discovery is fine. For security, I think the current consensus is just make the best choice you can, and if something really requires a major change, version the standard (major version, like from 1.x to 2.0, so it's obvious). Auto-discovery of a setting to do with security is just another possible location where a security issue might be found because or a poor implementation of the standard.
- MattJ100 5y ago
  Sure, but I don't think that applies here. The section in question is about a settings screen where (for some reason) the user is manually entering all the connection parameters. There is no way to detect (without probing) whether the port that the user configured is using STARTTLS or direct TLS. Both are commonly deployed. Probing could be implemented, but that quickly introduces complexity (and code just as likely for security issues to hide in) to implementations. It would be nice to one day say "only support direct TLS" for example, but that's not the reality of today's network (looks like ~41% of servers advertise direct TLS as of today, slowly climbing). So the happy path is using auto-discovery as standardized. If you go the manual path and configure a host/port, I don't think probing is sensible to recommend, and I don't think strictly assuming only one or the other is going to fly right now.
  - deleted 5y ago
    [deleted]
  - kbenson 5y ago
    Is this just for clients, or for servers as well? If it's for servers also, I guess that's a question of what you want this to be then. Is it a descriptive document that says "this is what Modern XMPP looks like as we see it in the wold" or a prescriptive document that says "This is what you need to do to be a modern XMPP deployment so we can fix some problems of the past". Maybe one way that might look is user clients that probe, but when defining how servers should act, there's a "one true way" unless they aren't adhering to Modern XMPP spec or best practices. Changes like this need a push from outside or they never happen, and someone just being able to point at a spec and say "look, you aren't compliant with Modern XMPP, the world has moved on from what you're doing" is incredibly useful in spurring change. I agree it doesn't necessarily make sense for a client options perspective, but it might be a good principle to adopt or consider for other aspects of the document. If you want to actually push things forward, I think it's very useful way to do so.

Lammy 5y ago

> When you are establishing a standard that clients and servers will advertise that they adhere to, don't leave technical decisions to the end-user by default. On principle I agree, but ironically the exact scenario you suggest was the single biggest event that "killed" XMPP as we used to know it. In late 2013 there was an XMPP community manifesto calling for mandatory TLS (even STARTTLS) for XMPP server-to-server communication by a drop-dead date in early 2014: https://github.com/stpeter/manifesto/blob/master/manifesto.txt https://github.com/stpeter/manifesto/blob/master/manifesto.t... "The schedule we agree to is: - January 4, 2014: first test day requiring encryption - February 22, 2014: second test day - March 22, 2014: third test day - April 19, 2014: fourth test day - May 19, 2014: permanent upgrade to encrypted network, coinciding with Open Discussion Day <http://opendiscussionday.org/ http://opendiscussionday.org/>" Well-intentioned for sure, but the one XMPP provider with an actual critical mass of users (Google Talk) remained non-TLS-only, all Google Talk users dropped off the federated XMPP network after May 2014, and so XMPP effectively ceased to matter.

MattJ100 5y ago
In fairness, by 2014 it was fairly obvious that Google was no longer interested in furthering Google Talk. It was about the time that they were pushing folk to Google+ and Hangouts. Google's XMPP server continued to accept unencrypted connections for many years after this point. I think the XMPP operators made the right choice, rather than letting Google weaken the security of the entire network.
- Lammy 5y ago
  > by 2014 it was fairly obvious that Google was no longer interested in furthering Google Talk Definitely, but I think it was a huge PR failure that we in the XMPP community were the ones to sever the conversational link. Users shouldn't be expected to think about the protocol details, hence this thread, and it was an XMPP community decision that resulted in people being suddenly unable to talk to their friends. We provided perfect justification for any Google project manager to look at the stats and see zero incoming s2s connections as justification to kill Talk entirely so they could Move Fast™ on Hangouts or whatever. I guarantee we pushed more overall XMPP users to WhatsApp/FB than we pushed Google Talk users to privacy-first XMPP hosts since it's not like Google popped up any alert in the GMail Talk UI explaining to people why their nerd friends all suddenly vanished from their buddy lists. The moment any of those people used a non-XMPP service to reach out and ask "What's up?" we had already lost :/

giancarlostoro 5y ago

Yeah, I would argue pick one secure way for the client to ask which one the server prefers and dont let the end-user even bother thinking about it.

southerntofu 5y ago
That's already what happens in practice, as defined in XEP-0368 SRV records for XMPP over TLS https://xmpp.org/extensions/xep-0368.html https://xmpp.org/extensions/xep-0368.html That UX description is intended for "additional connection options" prompts, which are useful when your server is misconfigured or you want to reach it in a different manner than advertized over DNS (eg. over a .onion address).
- giancarlostoro 5y ago
  Oh I see, that makes sense then. I didn't realize Onion instances needed special customization, is there no way to fix this UX?
  - southerntofu 5y ago
    Great question! onion vhosts (user@foobar.onion addresses) don't need that, as long as your client can resolve onion addresses (Gajim/Conversations have good tor integration, otherwise Tor's AutomapHostsOnResolve will do the trick systemwide but in that case your client may complain that the domain doesn't support TLS or with a wrong certificate). "Advanced" connection settings is required when the vhost you are connecting to doesn't match the hostname you need to reach on the network. For example, if you're reaching your server over a VPN/SSH/IPSEC tunnel. Another example is if you wish to login as user@foobar.com by reaching foobar.onion. This is useful if you want to be part of the broader Jabber federation, in which not every host supports federation over onion addresses (i'd be curious to make stats about that) but it still gives you the security guarantees of Tor when reaching your server (though not for server-to-server connections). Onion name discovery for automatically upgrading to onion routing when Tor is available client-side is not yet specified within the XMPP ecosystem. Onion discovery in the HTTP ecosystem is usually done via Onion-Location HTTP header (HTTPS only), in the email ecosystem they use _onion-mx DNS SRV records: see https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt https://gitweb.torproject.org/tor-browser-spec.git/tree/prop... and https://github.com/ehloonion/onionmx/blob/master/SRV.md https://github.com/ehloonion/onionmx/blob/master/SRV.md respectively Implementing something similar XMPP side would be easy. Prosody already has a community mod_onions, but currently only supports a static map of hosts to their onion addresses. It could use some love: https://modules.prosody.im/mod_onions.html https://modules.prosody.im/mod_onions.html Another problem we face from a UX perspective for onion services is that currently XMPP server implementations are very strict about which node/resource messages are intended for, and to my knowledge none support aliasing systems as we have in the email world. In this specific example application of aliases, there's currently no way (that i know of) to have the same account across .org/.onion domains and having servers to know it's the same account in a federated manner, eg. to prevent you from adding the same person twice to your contact list. All in all there's interesting challenges and none of them is really hard so if you'd like to get involved or just let us know about your ideas and expectations, feel free to drop by xmpp:privacy@joinjabber.org?join

nashashmi 5y ago

I understand where this is coming from. But this kind of early decision making can hurt the growth and adoption of projects. Think of it as Apple making a bunch of decisions for themselves and their users and it keeping problematic for future adoption. The spirit of open source is voluntary participation and openness to all platforms and ideas. Though I cannot understand the distinction behind TLS and STARTTLS , I don’t think locking in one option will make it all that better.

southerntofu 5y ago
> Though I cannot understand the distinction behind TLS and STARTTLS , I don’t think locking in one option will make it all that better. StartTLS starts unencrypted then "upgrades" the connection to TLS if the client and server support it. This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless. That's not to say TLS is perfect: having to trust an entire list of third-party CAs with their own incentives/pressures is a flawed model. But TLS is better than no TLS, so direct TLS is better than StartTLS.
- MattJ100 5y ago
  > This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless. This is a common misconception about STARTTLS. It is certainly possible to implement it poorly (and that has certainly happened). But there are no inherent security issues with a correct implementation. An active attacker can just as easily block TLS handshake packets on a direct TLS connection. The problem used to be that many software implementations (not just XMPP) would happily continue unencrypted if STARTTLS was not offered. But these days everyone requires TLS, and will not proceed to connect unless TLS is in use (regardless of whether it is negotiated or "direct"). However the future is certainly direct TLS, that has been obvious for some time. It has many advantages, such as allowing the use of off-the-shelf middleware such as loadbalancers and proxies, and bypassing certain firewalls. It's also easier to implement, and there is of course the (relatively new) ESNI which is beneficial.