I thought about something like this but it wasn't clear to me what negotiating channel binding would even mean. It also means that we have more state to keep around for when auth is negotiated, and more behavior and edge cases to figure out. If we negotiate channel binding, does the server *only* list SCRAM-PLUS mechanisms (ie does negotiating channel binding imply intent to use it)? What if we negotiate channel binding, then the server only lists SCRAM-SHA-1-PLUS but we only support SCRAM-SHA-256- PLUS? Do we fail when we would have otherwise been able to fall back to PLAIN (which would have been listed if not for the fact that we negotiated channel binding up front)? If the server continues to list all mechanisms, we just wasted round trips negotiating channel binding even though we'll never use it.
Furthermore, what if in the future we have multiple mechanisms that support channel binding (maybe we support issuing oauth tokens that use channel binding) but support different types (eg. oauth might use the token pinning spec that was in draft at the IETF recently… it was abandoned IIRC, but it's just an example). How do we convey that and make sure your channel binding feature is extensible? Having the list of mechanisms continue the trend of adding a suffix like "-PLUS" Means we can have all the context and state in one place, and pick a mechanism that works for us while remaining fully backwards and forwards compatible with what we have today. —Sam On Wed, May 6, 2020, at 12:50, Florian Schmaus wrote: > I am surprised about the design. Why inflate the SASL mechanism > namespace? Wouldn't something like > > <stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp- > sasl'> <mechanism>EXTERNAL</mechanism> <mechanism>SCRAM-SHA-1- > PLUS</mechanism> <mechanism>SCRAM-SHA-1</mechanism> > <mechanism>PLAIN</mechanism> </mechanisms> <sasl-channel-binding > xmlns='urn:ietf:params:xml:ns:xmpp- > sasl' required='false' > > > <channel-binding>tls-unique</channel-binding> </sasl-channel-binding> > </stream:features> > > Be way simpler and better? _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
