On Wed, 19 Oct 2022 at 14:23, Thilo Molitor <th...@eightysoft.de> wrote: > > 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.
> 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. 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. > > 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. I think there are two "tasks issue"s being confused here. The "tasks issue" that I was referring to (and I assume Daniel too) was specifically about the task syntax (base64 vs arbitrary XML payloads). I don't have a strong opinion on this right now, mainly because I haven't properly tried to use either format yet. While working on rough draft flows for MFA, I did find base64 and the next/continue framework very limiting, but I understand why the spec was written as it is, so I think any changes do deserve attention. 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. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
