Thank you Thilo. On Fri, Oct 24, 2025 at 4:00 AM Thilo Molitor <[email protected]> wrote:
> > To put what you wrote into actionable terms for the client developer: > > "If a client sees that that the server has 0440 support it MUST set > > the 'y' flag regardless of the concrete binding mechanisms announced > > by the server" > > > > Is this a correct summary of what you wrote? > No, no. Lets try to explain it from the client developer perspective. > As a client developer, do the following: > > 0) Servers MUST implement tls-server-end-point and enable/advertise it. > Clients SHOULD implement tls-server-end-point and use it if no other > (stronger) channel-binding method is supported by both sides. > > 1) If you don't support channel-binding, you MUST send "n" in the GSS-header > (RFC 5802). > > 2) If you support channel-binding, but you neither got SCRAM-*-PLUS nor > XEP-0440 channel-bindings announced by the server, you MUST send "y" (RFC > 5802). > > 3) If you're using SASL2 to authenticate and got SCRAM-*-PLUS, but no XEP-0440 > announced, you MUST abort the authentication (this is either an implementation > error or MITM). This is undefined with SASL1, but you MAY abort authentication > in this case (or just randomly pick a channel-binding and hope for the best). > > 4) If you're using SASL2 and see XEP-0440 channel-bindings announced, but no > SCRAM-*-PLUS methods, you MUST abort authentication (implementation error or > MITM). You SHOULD do the same when using SASL1. > > 5) If you're using SASL1 or SASL2 and see SCRAM-*-PLUS methods and XEP-0440 > channel-bindings announced, but *none* of these channel-binding types are > supported by you and tls-server-end-point isn't advertised by the server, you > MUST abort authentication (this is a MITM, as per rule 0). You SHOULD of > course use a channel-binding stronger than tls-server-end-point, if advertised > by the server and implemented by you (set the p=<channel-binding-name> GSS- > header). > > 6) All of this applies equally to other mechanisms that, like SCRAM, support > channel binding. Yes I guess with this ruleset in place defining a common, mandatory to implement channel binding mechanism makes sense. But this set of rules is definitely not obvious and I wasn’t really aware of that even though I consider myself as having some experience with the whole channel binding/SASL2 stack. So yeah. IDK. scrap the entire Security Considerations and replace it with that. ^ > > I hope this makes it more clear. I'm happy to draft a PR to add this list to > the XEP, if you want me to. > > Rule 0 is essentially what we were discussing in this thread. Yeah. But until now we have been discussing it without the context. > We should move > that out of the "Security Considerations" section and replace the entire > "Interaction with SASL mechanisms" section with the above list (see below). > My explanation why this is needed (from my last mail) could then go into the > Security Considerations section. Yeah I don’t have strong feelings of where in the XEP to put exactly what. But this should probably all go somewhere. In any case all that are only arguments for having one required binding mechanism. This still leaves the question if enough time has passed that we can make exporter that mechanism. cheers Daniel _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
