Show more

@Monal yes, I was part of similar discussion some time ago on xmpp maillist but while i supported the idea it's better to send n when you don't have mechanism to agree on binding type and you suspect that type you support is unlikely to be supported by tge server it's better to send n, but if server is not sending any -PLUS - y for me is a must have. Perhaps I need to undust my xmpp maillist and start it over there.

@Monal ok so the idea behind such scrutinity for SCRAM is to avoid user having false perception of being secure by using more secure mech? But if client choses plain - he's on his own and accepts all the risks.

@Monal server can then extract this attribute and compare it with own signature. heck it can even strip it and replace with own signature - either way being part of ClientSignature and hence ClientProof its tampering will break the auth.

@Monal Second problem is 474 is intervening into SCRAM mech by forcing undeclared server message. THere is compliant way to do that - optional extensions. I.e. we can include client hash as optional SASL extension attribute:
y,,n=me,r=E3F76B57-CBDE-46A3-979A-F9B1660B0685,g=1B86B264-2A11-4DEF-92C7-6ED78DAFBC95,h=0a1b2c3d4e5f
and that would include it into client-first-bare and hence part of AuthMessage and thus ClientSignature. SASL backend will just ignore it's meaning but keep in AuthMessage

@Monal First problem i see is that monal is sending n,, - it does support PLUS, but server advertised it's not, so it should send y,, instead indicating it didn't see PLUS in adv. That would already allow raising a flag to the server which actually advertised PLUS. That wouldn't allow catching downgrade to SHA-1-PLUS but would prevent downgrade to non-cb SCRAM mech.

@Monal but the whole point was to allow monal to use server with dovecot sasl provider. apparently I cannot force Dovecot to add some extra field to the SASL challenge this effort is futile then ;(

@Monal Ok so only way to use SCRAM is to implement 388 and 474, while PLAIN could be used without all the hassles? like really? :)

@Monal Ok, added 0388 implementation, not advertising -PLUS, and getting now this:
_incomplete XEP-0388 support, XEP-0440 MUST be implemented and this mandates that servers MUST at least implement tls-server-end-point__
Ok, fair enough, if server sent PLUS, but it didn't

@mcSlibinas @GossiTheDog we will see in two weeks, maybe someone fells out maybe not. Of course FAKE NEWS are telling we are not doing anything about it.

@Monal yup got it so i need to use /authentication:urn:xmpp:sasl:2 in features instead of /mechanisms:urn:ietf:params:xml:ns:xmpp-sasl for it to accept scram.

@Monal I have a question, cannot find it in FAQ/mans. Is monal *only* supporting SASL SCRAM-SHA-*-PLUS now? I'm offering SCRAM-SHA-256 but it closes the stream and shows "weak auth" error. a bit odd and there's no setting to turn it off

@briankrebs narcissist of nth degree most likely is sociopath, but sociopath does not necessary is narcissist

@dcz they are needed elsewhere in big quantities

@CamWeck classic capitalism, the more people maintain their cybertruck finish with saltwater and lemon juice the less service fee tesla collects, hence all the suppression and denials of the obvious facts

@arstechnica yes, that's why it's not a "military grade", is it a news to someone?

@SwiftOnSecurity Sorry I missed the alignment meeting, what does the vertical axis represent?

@SwiftOnSecurity Oh yes it was, I was really disappointed to find the citadel reduced to mere one room (with appendices) in me2 and some narrow tower in me3

Show more
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml