On Thu, 11 Jan 2024 at 12:49, Simon Josefsson <simon@josefsson.org> wrote:
tor 2024-01-11 klockan 13:39 +0100 skrev Holger Weiß:
* Simon Josefsson <simon@josefsson.org> [2024-01-11 13:10]:
I believe tls-server-end-point is generally best left unimplemented to guide efforts towards supporting the stronger tls-exporter.
One use case I see for tls-server-end-point is that it allows for supporting channel binding by setups where TLS is terminated by some reverse proxy, thereby protecting against _some_ but not all attack vectors that tls-exporter protects against.
Indeed -- however I think the burden to support those kind of environments should be on the entities chosing to deploy and use those kind of environments, instead of placing the burden (and weakening security) for everyone else.
While I think it is acceptable for standards to acknowledge and allow insecure usage modes (with proper caveats), I believe the primary purpose and default recommendations for a standard should be to promote secure behaviour. That is not achieved in XEP-0440 now.
A compromise would be to mandate both tls-exporter and tls-server-end- point, however I'm hoping the short period that tls-server-end-point has been mandated can be ignored and we can select a better mandatory method.
Thankfully I think all server implementations took sensible routes already (i.e. everyone who supports channel binding has tls-exporter implemented, in current or current+1 releases). Prosody will automatically offer tls-unique/tls-exporter, and tls-server-end-point by default unless explicitly configured by the admin. I think the logic for the wording in the XEP was because some deployments cannot (easily) use the algorithms with dynamic values, so tls-server-end-point is seen as the lowest common denominator, and recommended from an interoperability perspective (some channel binding is better than none at all). However I think that the difficulties deploying tls-unique/tls-exporter that exist today could be overcome with sufficient support from TLS middleware. I'm not aware of any such support right now though. Regards, Matthew