Hi Daniel, Daniel Gultsch wrote: > Inline + User-Agent good. Very skeptical on forbidding PLAIN and the dependency on channel binding. It's not forbidding PLAIN, but highlights what is already described in RFC 6120 section 13.8.3, but seems to have been forgotten: PLAIN should not be used if it's not absolutely needed. Why is that so? Because any channel-binding falls apart if the client supports PLAIN. Thus it's always possible to downgrade the client to use PLAIN.
A client supporting PLAIN will never have to implement SCRAM nor channel- binding. Implementing these just does not make any sense if an attacker able to break into the TLS layer can always downgrade authentication to use PLAIN, circumventing any SCRAM or channel-binding. If, on the other hand, we assume TLS to always be secure, than we won't have to implement SCRAM and channel-binding either. There is no need in implementing SCRAM or channel-binding to secure something we deem to be always secure by definition. Today almost every client still supports PLAIN and will happily negotiate it without any warning to the user and without being hidden behind a "Activate legacy authentication" knob that has to be enabled by the user first. Now to the dependency on channel-binding: that was not meant to be a hard dependency, but if a client or server supports channel-binding it MUST use XEP-0440 to negotiate which binding to use. And it SHOULD only use upgrade tasks if channel-binding is in use to make sure an attacker won't be able to intercept the SCRAM hash (or any other authentication data) that could later be used to impersonate the client/user. If I accidentally made the channel-binding a hard dependency, I'm happy to fix that. Just point me to the part of the XEP I should change. > I don’t yet have on opinion on the tasks issue. Well, if we don't have a way to upgrade the SCRAM hashes stored on the server, we won't be able to gradually phase out SCRAM-SHA-1 to use the more secure SCRAM-SHA-256. You'll either have to store the password on the server in plaintext or only offer SCRAM-SHA-1. There are good reasons to not store passwords in plaintext on the server, but use salted hashes: https://prosody.im/doc/plain_or_hashed Prosody even defaults to hashed now. That means you won't be able to upgrade to SCRAM-SHA-256 if these upgrade tasks weren't included in SASL2. (You could of course force the complete userbase of a server into resetting their passwords to switch from SHA-1 to SHA-256, but that's obviously very bad UX.) This upgrade problem has been mentioned in 2019 here on list already: https:// mail.jabber.org/pipermail/standards/2019-January/035720.html I've written a blog post that more or less describes all of the rationale behind my changes to this XEP over here: https://monal-im.org/post/00004-sasl/ -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
