On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch <[email protected]> wrote: >
> And yes we are currently implementing it. That's why I’m providing > feedback on the XEP. And yes we are using it with compression and yes > we do terminate TLS early and can’t use HT-* and yes we use PLAIN for > regular logins too and therefor we don’t have an issue with the > "downgrade" in security. I'm also looking at potentially implementing it in Prosody very soon, as part of the modern auth project ( https://docs.modernxmpp.org/projects/auth/ ). My main motivation is support for 2FA, which is impractical without a way for devices to re-identify themselves (you don't want an OTP prompt every time your mobile reconnects to the server). ISR seems to be a good way to fill that gap, while providing other benefits. The alternative on my radar is XEP-0399 (Client Key). I do agree that while the goals of enforcing channel binding are noble, it is impractical to enforce across the network. It excludes web clients and a bunch of deployments that terminate TLS before the XMPP server. What are thoughts on a HT- variant without channel binding (and adding RFC 9266's tls-exporter while we're at it)? Combined with ISR's mechanism pinning, I think this still provides some advantages over just using PLAIN (which is icky, but the alternative). Thoughts and/or guidance welcome. I'm particularly interested to hear input from client developers. A lot of our community discussions have an element of "it would be nice if we could...", but I'm actually working on this project right now, it has time constraints, and whatever I end up implementing will be in the next Prosody release. It would be super if whatever gets rolled out is actually something developers *want* to interact with. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
