On Thu, May 7, 2020, at 12:21, Florian Schmaus wrote: > That the remote entity, the server in c2s, supports those particular > channel binding types.
Okay, I assumed you meant that this would be a separate stream feature, but from the examples you gave it doesn't seem like that's what you're suggesting. In that case, read on… > <stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp- > sasl'> <mechanism>EXTERNAL</mechanism> <mechanism>SCRAM-SHA-1- > PLUS</mechanism> <sasl-channel-binding xmlns='urn:ietf:params:xml:ns:xmpp- > sasl'> <channel-binding type='tls-unique'/> </sasl-channel-binding> > </mechanisms> </stream:features> Can we modify the mechanisms feature? Having this be an extension to the mechanisms feature seems problematic to me. If I have a stable library that implements XMPP SASL can I add this new payload to my library without making backwards incompatible changes? Do I have to maintain a new feature that just advertises the same name as the old mechanisms feature? This feels poor. Also if you're someone using strict schema validation and you don't support the sasl-channel-bindings extension yet, this will break you if the other end does. We'd need a mechanisms version bump or some other way to tell if we should expect this payload. > As other said, I too find not necessary to plan for the world where a > channel binding type exists that can only be used with a particular > SASL mechanism. The TLS Exporters channel binding mechanism, which in the future will likely be the primary way any channel binding happens with TLS says that you SHOULD mix in application level data, eg. data specific to SCRAM in this case so that the binding is two ways. This means we need to plan for people doing that, whether we intend to do it ourselves or not. —Sam -- Sam Whited _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
