What happens if a malicious server starts reporting that it no longer supports SRP or that the client does not have SRP configured? It will take some really good UX design by clients to ensure that the client doesn't fall back to a regular login and leak the password to the server.

Yeah, this is a big one, for quite a while we won't be able to assume the server has no access to the plaintext password. I would imagine that the long-term solution is to remove the password authentication from the matrix spec, and declare all apps still supporting the old password login as incompatible.

I added some thoughts about this. Do you have any additions?

I think that is fine. I don't think there is way to enforce it yet. Maybe add a note that clients can consider indicating when SRP is/isn't used. Maybe that indication would even take a while to be enabled by default but it provides a nice path away from sending the password to the server.

1. Opportunistic, the client uses SRP if advertised.
2. Recommended. The client warns if SRP isn't going to be used. (Or shows a "lock" if it is)
3. Enforced. The client refuses to send the password to the server. (At least without some very explicit disclaimer)

Of course we shouldn't mandate client behaviour, however I think it is often helpful to explain what it could look like.

This raises an interesting question about how the Matrix user-interactive auth is supposed to work.

For a stage that requires multiple rounds of communication, should the type be the same for every request? ie, here it would be m.login.srp6a for both init and verify, and the details would go in the auth object.

Or should each "round" of communication be its own UIA stage? In that case, it seems like the flows returned by GET /_matrix/client/r0/login should include both stages, ie ["m.login.srp6a.init", "m.login.srp6a.verify"].

The flow only has one GET request at the very start, so returning just m.login.srp6a seems like it's sufficient to me, supporting just init or just verify makes little sense so I would argue that's implied.

If we compare against the webrtc spec (which also has multiple stages) I think using m.login.srp6a.init and m.login.srp6a.verify in POST to /login makes sense. (webRTC in matrix use m.call.invite, m.call.candidates, m.call.answer and m.call.hangup). We defined an auth_id in this MSC because we do need to keep track of the flows, you can't verify before having done the init.

Then again: srp can map fairly well on the UIA, but that's a seperate MSC and I kept that out of scope here because there's no reason either this msc or the UIA msc needs to depend one another.

Doh, I think I was getting confused between the UIA vs normal login. I thought at some point they were going to all use the UIA? Or maybe that was just a proposal that I saw.

I think so too, I may have missed that the proposal got merged?

Of course this MSC actually needs to support UIA, because authentication doesn't only happen at /login so this is added now. It's more or less a duplicate of /login except all SRP json stuff in put inside an auth object.

Should these groups, the password hashes and the hash functions be put under the m.* prefix. This way it is obvious to clients how to add more, and which ones are "official" as part of the spec.