On Thu, 11 Jan 2024 at 12:49, Simon Josefsson <[email protected]> wrote: > > tor 2024-01-11 klockan 13:39 +0100 skrev Holger Weiß: > > * Simon Josefsson <[email protected]> [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 _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
