Yeah, that discussion in the summer was really long, but much appreciated by me!
The SSDP XEP mainly tries to fill the gap described in XEP-0440 Security Considerations [0]: > If a client signals to the server that he does not support channel binding, because it found no mutual supported channel-binding types, another MITM attack vector is introduced. An active attacker could replace the <sasl- channel-binding;> list with channel bindings unlikely (or impossible) to be supported by the client. If the client is configured to use non-channel-binding SASL mechanisms as a fallback, this could be used to downgrade the connection security. Note that this attack is a different one than the SASL-mechanism stripping one: Here the attacker tempers with the announced channel-binding types, i.e., the values within <sasl-channel-binding;> XEP-0440 suggests pinning the channel-binding. That could have negative side effects and prevent successful connections by clients, if the server operator decides to change the channel-binding mechanism (for example by downgrading from tls-exporter to tls-server-end-point because his server got big enough to need extra TLS termination/load balancing). XEP-0474 tries to solve these problems without introducing the negative side effects of pinning. But it requires the server operator to disable SASL PLAIN. (I'd argue most server operators not depending on an LDAP backend or somesuch could disable SASL PLAIN.) > And if this isn't making things better, are we better off talking about > clients latching on preferred mechanisms? No, latching on some mechanisms does not make things better, see above. It is some sort of last resort, if you can't come up with something better. But XEP-0474 *is* better. It avoids all the problems with pinning, only introducing a dependency of not using/providing SASL PLAIN. But you already should not use/provide that if you can avoid it. That's even suggested in § 13.8.3 of RFC 6120. > Out of curiosity, if we were to say that the mechanisms and TLS channel > bindings stream features were repeated after the authentication (perhaps as > actual stream features, but more sensibly somewhere else - <success/> and > <continue/> possibly?) would this satisfy the requirements better? > Differently? Not at all? The goal of XEP-0474 is to cryptographically secure the XEP-0440 channel- binding list even in the presence of a TLS-MITM. When sending the list again after authentication, a TLS-MITM able to survive the authentication by advertising some fictional channel-binding types not supported by the client to force it to not use channel-binding (and otherwise only relaying the SCRAM authentication messages) will be able to intercept and change the channel-binding list sent after authentication, too. You can send the channel-binding list as often as you want, you can't change that. By using the SCRAM (and later on OPAQUE) cryptography we essentially can bind the tls channel-binding list offered by the server to the knowledge of the SCRAM password, efficiently detecting the TLS-MITM. By the way: I already tried to explain some of the rationale behind this XEP in great detail on this list [1], too. -tmolitor [0] https://xmpp.org/extensions/xep-0440.html#security [1] https://mail.jabber.org/pipermail/standards/2022-October/039025.html Am Freitag, 30. Dezember 2022, 11:35:48 CET schrieb Dave Cridland: > On Tue, 13 Dec 2022 at 18:04, Jonas Schäfer <[email protected]> wrote: > > Version 0.1.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been > > released. > > I had a long discussion off-list with Thilo on this, and I broadly think it > has very little utility - at best, you can tell if you've been downgraded > *to* a SCRAM-family mechanism, but one that is still considered secure > (since otherwise the attacker could trivially forge the ssdp SCRAM > attribute). So this surely only detects a downgrade when the downgrade > hasn't been successful. No? > > Out of curiosity, if we were to say that the mechanisms and TLS channel > bindings stream features were repeated after the authentication (perhaps as > actual stream features, but more sensibly somewhere else - <success/> and > <continue/> possibly?) would this satisfy the requirements better? > Differently? Not at all? > > And if this isn't making things better, are we better off talking about > clients latching on preferred mechanisms? _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
