18 ms·

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 m

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.
    - MattJ100 5y ago
      This project is certainly aiming to push things forward. Indeed a decade ago it would be totally unsurprising to see a client with a drop-down for "STARTTLS", "Direct TLS", "No TLS" (!). I think it's best described as something of an evolving "current best practices" document. There is certainly room to tell developers to implement (or not implement) certain features. Indeed that is done already for some things (e.g. file transfer mechanisms). I think this specific TLS example is unfortunate because it's something that is documented only for advanced use (recognising that some people may need it for specific purposes that some clients may want to support).
      - Macha 5y ago
        Similarly, I remember implementing an Android IRC client years ago and having to provide an option in a dropdown not to verify the TLS certificate since so many servers ran self signed certs at that time (thankfully Lets Encrypt put a stop to that).

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.
  - MattJ100 5y ago
    This project is certainly aiming to push things forward. Indeed a decade ago it would be totally unsurprising to see a client with a drop-down for "STARTTLS", "Direct TLS", "No TLS" (!). I think it's best described as something of an evolving "current best practices" document. There is certainly room to tell developers to implement (or not implement) certain features. Indeed that is done already for some things (e.g. file transfer mechanisms). I think this specific TLS example is unfortunate because it's something that is documented only for advanced use (recognising that some people may need it for specific purposes that some clients may want to support).
    - Macha 5y ago
      Similarly, I remember implementing an Android IRC client years ago and having to provide an option in a dropdown not to verify the TLS certificate since so many servers ran self signed certs at that time (thankfully Lets Encrypt put a stop to that).