[MattJ100]

> Is there a reason why dialback isn't the answer?

There are some advantages to using TLS for authentication as well as encryption, which is already a standard across the internet.

For example, unlike an XMPP server, CAs typically perform checks from multiple vantage points ( https://letsencrypt.org/2020/02/19/multi-perspective-validat... ). There is also a lot of tooling around TLS, ACME, CT logs, and such, which we stand to gain from.

In comparison, dialback is a 20-year-old homegrown auth mechanism, which is more vulnerable to MITM.

Nevertheless, there are some experiments to combine dialback with TLS. For example, checking that you get the same cert (or at least public key) when connecting back. But this is not really standardized, and can pose problems for multi-server deployments.

> It has never been secure to accept the clientAuth EKU when using the Mozilla root store.

Good job we haven't been doing this for a very long time by now :)

[agwa]

Ah, I didn't know that dialback doesn't use TLS. That's too bad.

[MattJ100]

Sorry, it's late here and I guess I didn't word it well. Dialback (these days) always runs over a TLS-encrypted connection, as all servers enforce TLS.

The next question is how to authenticate the peer, and that can be done a few ways, usually either via the certificate PKI, via dialback, or something else (e.g. DNSSEC/DANE).

My comment about "combining dialback with TLS" was to say that we can use information from the TLS channel to help make the dialback authentication more secure (by adding extra constraints to the basic "present this magic string" that raw dialback authentication is based on).