Hi Dave, > Not using PLAIN is insufficient - clients have to only use SCRAM, and in > particular, variants of SCRAM that are considered secure. Not exactly true. One could design a channel-binding downgrade detection for SASL-EXTERNAL using client certificates, too. But I wanted to start with the most common SASL mechanisms used in the wild by xmpp servers. And SSDP can be used for OPAQUE, too, just by defining the exact same optional attribute for OPAQUE that SSDP is defining for SCRAM. In fact I might update the XEP to define the same protection for OPAQUE, too.
> So yes, if someone is deploying SCRAM-SHA256, this would detect a downgrade > to SCRAM-SHA1, but only while SCRAM-SHA1 is proof against compromise. And > while SCRAM-SHA1 *is* proof against compromise (modulo leaks of the server > credential store), a downgrade to it isn't really something to worry about > (and why is an attacker doing this?). I would therefore argue this provides > no practical protection against downgrades of SASL mechanisms. You assume that "compromise" always means the attacker would be able to break the SCRAM handshake in realtime to change the SSDP hash and make SSDP useless. But SCRAM-SHA-1 could once well be broken in the sense that it costs x days of computation time to break it and recover the password / hash. In such cases detecting the MITM and alerting the user would allow the user to change the password and prevent the attack this way. > Therefore, this is *at best* protecting against changing the channel > binding type to support only channel binding types that the client does not > support, or are weak enough to be under the attacker's control. Well not exactly (see above), but well, as I said before: the main goal of SSDP is to detect/prevent channel-binding downgrades. > Maybe it'd be better to start with a concrete example of an attack, > demonstrate its utility to the attacker, and then show how this prevents > the attack? I'm under the impression I constantly explain the same thing over and over again, see [1] or even the Security section of XEP-0440 [2] for example. But well, let's do it again... I'm a MITM attacker using either a stolen cert+key or I've managed to somehow get a CA signed cert+key combination. How I did this is out of scope here, maybe I hacked the mailserver and some CA is still using domain validation via email, or the user installed the corporate/school CA and now gets MITMed by his employer/school etc. No matter how: now I can MITM the TLS connection, but channel-binding will detect this and fail the authentication, maybe even inform the user. To be able to read incoming and outgoing xmpp stanzas or even manipulate them, I need to get rid of channel-binding. I manipulate the channel-binding list the server is advertising to only list dummy channel-bindings the client does not support. Now the client has two choices: fall back to no channel-binding at all (I, the attacker, win) or abort authentication. Aborting authentication may be bad, because protocol agility might introduce new channel-binding mechanisms the client does not know and a server might be configured to only support these. The client would effectively DOS itself in this scenario. Pinning the channel-binding method is of limited use, too (see my last mail) and can also easily result in DOS. That means, as a client developer, I have no good option at hand. That's what SSDP is trying to solve by providing a mechanism to detect such downgrades without all of the downsides of pinning which is only an incomplete solution to this problem. Please note: in the case of a stolen cert+key I can just downgrade from tls- exporter to tls-server-end-point instead of downgrading from channel-binding to no channel-binding. But other than that, the attack above is still the same: Without SSDP I can MITM the connection without server and client noticing it. -tmolitor [1] https://mail.jabber.org/pipermail/standards/2022-October/039025.html [2] https://xmpp.org/extensions/xep-0440.html#security _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
