On Wed, 19 Oct 2022 at 16:02, Thilo Molitor wrote:
> Am Mittwoch, 19. Oktober 2022, 16:32:55 CEST schrieb Dave Cridland:
> > Small point: GS2 doesn't ever allow clients to know if channel binding is
> > proven, since the channel binding data is passed in the clear to the
> > server. It does
Am Mittwoch, 19. Oktober 2022, 16:32:55 CEST schrieb Dave Cridland:
> Small point: GS2 doesn't ever allow clients to know if channel binding is
> proven, since the channel binding data is passed in the clear to the
> server. It does prove the server saw the channel binding data as sent by
> the
On Wed, 19 Oct 2022 at 14:59, Thilo Molitor wrote:
> That's a wekness of SCRAM itself. Channel-binding problems will be
> detected
> after the client-final-message as well.
>
Small point: GS2 doesn't ever allow clients to know if channel binding is
proven, since the channel binding data is
Hi Marvin,
> I think the specification partially exaggerates on what it is able to
> actually achieve security-wise.
>
> The requirements say: "Allow detection of SASL mechanism downgrades
> even if no channel-binding is in use.". However, as this is an
> extension to SCRAM, it only allows
Hi Peter,
> 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:
>
Hi Daniel,
Am Mittwoch, 19. Oktober 2022, 09:23:10 CEST schrieb Daniel Gultsch:
> > But that leaves clients not able to implement this type, or any
> > channel-binding at all, vulnerable to downgrades of channel-binding types
> > and SASL mechanisms.
> This specification protects clients that are
> But that leaves clients not able to implement this type, or any
> channel-binding at all, vulnerable to downgrades of channel-binding types and
> SASL mechanisms.
This specification protects clients that are not able to support
channel binding from being tricked into thinking the server
I think the specification partially exaggerates on what it is able to
actually achieve security-wise.
The requirements say: "Allow detection of SASL mechanism downgrades
even if no channel-binding is in use.". However, as this is an
extension to SCRAM, it only allows detection of SASL machanism
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
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
On Wed, 12 Oct 2022 at 17:17, Jonas Schäfer wrote:
> Title: SASL SCRAM Downgrade Protection
> URL: https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html
Any attacker able to manipulate the data coming from the server such that
the client sees a restricted set of TLS channel bindings
I thought we had automatic pulls of the built images... apparently we don't,
pulled manually, fixed, thanks for the hint.
On Samstag, 15. Oktober 2022 16:34:20 CEST Dave Cridland wrote:
> 404?
>
> On Wed, 12 Oct 2022 at 17:17, Jonas Schäfer wrote:
> > The XMPP Extensions Editor has received a
404?
On Wed, 12 Oct 2022 at 17:17, Jonas Schäfer wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: SASL SCRAM Downgrade Protection
> Abstract:
> This specification provides a way to secure the SASL and SASL2
> handshakes against method and channel-binding
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: SASL SCRAM Downgrade Protection
Abstract:
This specification provides a way to secure the SASL and SASL2
handshakes against method and channel-binding downgrades.
URL:
14 matches
Mail list logo
