11 Jan
2024
11 Jan
'24
6:02 a.m.
On Thu, 11 Jan 2024 at 12:49, Simon Josefsson <simon(a)josefsson.org> wrote:
tor 2024-01-11 klockan 13:39 +0100 skrev Holger Weiß:
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
* Simon Josefsson <simon(a)josefsson.org>
[2024-01-11 13:10]:
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. 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.