4 ms·

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 conn

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).

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).