Hi Matthew, > There are deployments that require PLAIN. That is unlikely to change > (ever). However this doesn't stop clients from being smart, e.g. by > pinning support for SCRAM and refusing to downgrade. I don't know if > any clients actually do this. Yes, those deployments do exist. But 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.
While pinning is a valid approach it has some downsides, too. It does not cover the first connection and depends on ordering of mechanisms. If you upgrade the pinning to stronger mechanisms as soon as the server advertises them, you'll break authentication for your client if the server operator just briefly activated these stronger mechanisms and deactivates them again. If you don't upgrade your pinning, your client will remain on a sort of security baseline that eventually will be outdated over the years and virtually be as good as no pinning at all. Because all of these I consider pinning to be some solution of last resort if you can't come up with something better rather than a go-to solution one should always use. > There is a separate issue which was brought up by Dave in his review, > which is the inclusion of the upgrade tasks in this XEP. As far as I > am aware, nobody is opposing the upgrade tasks themselves (I certainly > think they are desperately needed). The problem is that they are not > part of the SASL2 framework itself. Just like we don't plan to define > every possible post-authentication task in this XEP, these tasks are > mechanism-specific and they don't need to be in XEP-0388. Copy/paste > them into a new document, and I think everyone will be happy. 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 -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
