On 12/2/20 8:36 AM, Dave Cridland wrote: > > > On Wed, 2 Dec 2020 at 14:09, Sam Whited <s...@samwhited.com > <mailto:s...@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.
Well, in 1999/2000 it was hard (for some definition) to get certs at all. Dialback was a bootstrapping mechanism for server deployment (along the lines of IBR for c2s) and I agree deserves to be deprecated now. > 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 > <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. > > Proposal: > > 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. Will that actually speed things up? Multiplexing would be a new protocol for server developers to implement and for server operators to deploy. Just wondering. :-) Peter _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
