Hi all, the SASL2 update consists of various parts. Mixing them doesn't help our discussion and I guess most people will loose track sooner or later. I will therefore start a new thread for every part, to discuss them separately.
I also want to stress what MattJ already said: > New Bind 2 (and SASL2) is already implemented by at least Prosody, > Conversations and Monal. We learnt a lot from our collaboration > and testing, and have tweaked and improved various things along > the way as we discovered what did and didn't work well during > implementation. Overall, I'm pretty happy with what we have working. -tmolitor Am Donnerstag, 20. Oktober 2022, 13:49:50 CEST schrieb Marvin W: > Hi Thilo, > > On Wed, 2022-10-19 at 21:41 +0200, Thilo Molitor wrote: > > I want us to move away from that "PLAIN is sometimes needed, let's > > support > > it in all relevant clients without further interaction by the user > > and ignore > > any security implications this might have" stance that seems be > > common, to > > something like "only support PLAIN in clients after configured to do > > so, to not > > allow for trivial MITM attacks". > > That's essentially a "default secure" rather a "default insecure" > > approach. > > You make it sound as if PLAIN over TLS was anywhere near insecure. It's > not. It's what is protecting your emails, your online banking, your tax > declaration, ... (at least on first connection, some of these can store > a token for further use instead of the plain password). > > The main advantage of SCRAM is that clients don't need to store the > plain password, but can store the SaltedPassword instead. This is still > a valid credential, but it is restricted to the server (as each server > would have it's own salt), so if users reuse passwords (which they > shouldn't, but do anyways), it's not as much of an issue, if the XMPP > client is attacked, as only the XMPP account would be affected. > > Under certain extreme conditions it might be sensible to put some kind > of additional security to TLS, for example Signal is known to use > certificate pinning with their own CA. And for these special cases it's > worth having something like SCRAM with channel binding specified (and > both defaulting to it and pinning to it is somewhat sensible). > > But that doesn't mean we should frame PLAIN over TLS as insecure. It's > not. It also doesn't allow for trivial MITM attacks: If a public CA was > to issue certificates it shouldn't issue, it will get banned > immediately (and thanks to certificate transparency we will learn about > this close to immediately). And if a private CA was installed onto a > system, the attacker could have installed malware at the same time, > that would be able to fish the user's password and thereby break > SCRAM's channel binding. > > Given that there are always usecases where SCRAM cannot be used (RFC > already mentioned PAM and LDAP, but there are even further, basically > everything where credentials are not handled by the XMPP server itself) > > > I've split out the SCRAM upgrade task definition into a new ProtoXEP: > > https:// > > github.com/tmolitor-stud-tu/xeps/tree/scram-upgrades > > Rendered version: > > https://dyn.eightysoft.de/final/xep-scram-upgrade.html > > Just wanted to mention that this specification isn't really a "SCRAM > upgrade", but rather a "change salted password" specification (which > might be an interesting idea to have, but that's another story), > because the server has no way to verify that the salted password is the > same as the previous one when upgrading from SCRAM-SHA-1 to SCRAM-SHA- > 256. > > I also question the proposed upgrade mechanism in general. The server > can only suggest mechanisms independent of the user's account name. If > the server previously only stored SCRAM-SHA-1 secrets and some users > upgraded but others didn't, the list can't be used meaningfully. What > we'd need here is a new error code for the server to tell the client > after the <authenticate> message that the user can't use SCRAM-SHA-256 > yet, but will be able to do so after some upgrade operation being > performed (which probably entails sending the password in plain). > A client that is trying to do SCRAM-SHA-256 when the server doesn't > have matching credentials yet must have the plain password at hand > already (as it can't have the SaltedPassword yet due to lack of salt), > so it is already prepared to provide it. If channel binding is desired > for security reasons, one could also do a SCRAM-SHA-1-PLUS before > sending the password to the server in plain. > > Marvin > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
