On 10/17/22 5:27 PM, Thilo Molitor wrote:
Thanks for your feedback Dave!
Am Montag, 17. Oktober 2022, 15:36:56 CEST schrieb Dave Cridland:
Any attacker able to manipulate the data coming from the server such that
the client sees a restricted set of TLS channel bindings can also
manipulate the data coming from the server such that the client sees a
restricted set of SASL mechanisms, removing SCRAM entirely.
That's the reason why PLAIN is strongly discouraged.
Of course you'll need mechanisms providing mutual authentication like SCRAM or
the upcoming OPAQUE mechanism.
Yes, this downgrade protection does not work for all scenarios. It's not
perfect, but it's a step in the right direction and really simple to
implement. It's even fully backwards compatible.
Most public servers today support only SCRAM and PLAIN anyways. So encouraging
them to disable PLAIN and adding this downgrade protection would be enough to
secure all these servers against downgrade attacks.
Moreover, if the client wants to use a stronger mechanism - let's say one
of the OPAQUE mechanisms in development - then it loses this protection.
Yes, sure, the same protection has to be defined for OPAQUE, too.
That shouldn't be a problem: if I read the early draft of OPAQUE correctly, it
provides support for optional attributes like SCRAM does (it even tries to use
the same characters for mandatory attributes like SCRAM).
In any case, if the client has a local policy not to use PLAIN (or other
mechanisms that it considers to be too weak), then it simply wouldn't
use those in case of a downgrade attack. Similar policies are in place
already for things like old versions of TLS, see here:
https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-11#section-3.2
Either way, I'd like more/different eyes on this - I'd highly recommend
taking this work to the IETF Kitten working group and seeing what they say.
Sure, I even stated in the XEP that I plan to eventually make this an I-D.
That said, I wanted to gain some implementation and operational experience
before going the next step forward.
Having this as an experimental XEP implemented in, for example, prosody or
ejabberd and Monal/Conversations would allow us to gain exactly this
experience.
This XEP was never meant to advance to stable, but to remain experimental and
be superseded by a proper RFC some day.
IMHO it is fine to advance a XEP to Draft and then obsolete it when the
proper RFC is published. We have done this before, e.g. XEP-0029.
Peter
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
