[Standards] Deprecating Dialback

Dave Cridland dave at cridland.net
Wed Dec 2 15:36:52 UTC 2020

On Wed, 2 Dec 2020 at 14:09, Sam Whited <sam at samwhited.com> wrote:

> I've been having a think about dialback recently and came to the
> conclusion that it would be nice to begin discouraging its use on the
> public network. This would raise the overall quality of authentication
> on the network by beginning to phase out insecure DNS-based
> authentication as well as simplify the implementation of certificate
> based auth by allowing us to only rely on SASL EXTERNAL without having
> to also implement "dialback without dialing back". Towards that end, I
> would like to propose deprecating XEP-0220 and XEP-0185.

There are two things here:

a) Phasing out DNS-based authentication - ie, db:verify.

b) Phasing out the use of the db:result syntax.

The DNS side, (a), is easy to suggest deprecation. It's fundamentally weak,
and it really only served a useful purpose before Let's Encrypt came along.
So I'm perfectly happy to see this deprecated - even though XEP-0344
suggests that DNSSEC and TLS provide pretty broad security even in this

XEP-0288 refers to dialback, but broadly is unaffected by deprecation of
(a) and (b).

But we don't have a solution without <db:result/> for "piggybacking", as
described in XEP-0220: https://xmpp.org/extensions/xep-0220.html#multiplex

I think multiplexing has value in a number of cases, particularly where S2S
bandwidth and/or latency is poor.


1) Pull multiplexing out into its own XEP.

2) Give it a new syntax (and a stream feature) that doesn't imply XEP-0220
anymore. Reference the old syntax as a historical case.

With that in place, I think we can deprecate XEP-0220

Note that I'm not suggesting we immediately rip the support out of every
codebase, just that we're suggesting it's no longer desirable or necessary
for servers to implement.

How does that sound?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20201202/b3f4d56d/attachment.html>

More information about the Standards mailing list