On 5/10/20 3:42 PM, Sam Whited wrote: > On Sun, May 10, 2020, at 08:53, Dave Cridland wrote: >> I'd be fine with putting channel bindings alongside mechanisms, just >> not pretending they are mechanisms. > > I still don't see why it bothers anyone. We already do this with "- > PLUS", so what is wrong with adding another suffix?
"Look, they did the same bad thing here, then it must be OK if I do the
same", is no argument.
> So far it's just "I
> don't like it" and "I'm not fine with it". I can't really do much to fix
> it if I don't know why.
It (1) unnecessarily bloats the SASL mechanism space with (2)
unregistered mechanisms while (3) additionally adding a lot of redundant
information.
1: It is a small combinatorial explosion if we list the cross product of
SASL mechanism and channel binding type in <mechanisms/>, for no reason
(see below).
2: All those mechanisms do not, and very likely will never, appear in
the IANA SASL mechanism registry.
3: Since you can assume that if a server (or implementation in general)
supports a channel binding type, it is supported for all SASL
mechanisms. Your suggestion repeats that same information, the supported
channel binding types, multiple times.
Now, I know you argue that there may be in the future channel binding
types that are specific to a SASL mechanism. Please read below why we
could still go with a way simpler and terse syntax.
>> It *is* possible that a server might not support all channel bindings
>> equally, but I think that server would be broken.
>
> What I was trying to say is that I don't think the server can always
> support all channel bindings equally, no matter how much we want it to,
> not just that it might not want to.
>
> For example, in my tls-exporter I-D [1] I am currently mixing in part of
> the SCRAM messages which makes it SCRAM specific. This *cannot* work
> with other non-SCRAM mechanisms that support channel binding (such as a
> future OAuth mechanism).
Even if there is a channel binding type that is specific to a SASL
mechanism, then the server announcing
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>EXTERNAL</mechanism>
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
<mechanism>PLAIN</mechanism>
<sasl-channel-binding xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<channel-binding type='tls-server-end-point'/>
<channel-binding type='tls-exporter'/>
</sasl-channel-binding>
</mechanisms>
</stream:features>
would be sufficient for the client to now what do to. Even if
'tls-exporter' is SCRAM specific, because its specification then surely
would declare the supported SASL mechanisms.
> Now, since writing that I've decided that the value that we want to mix
> in probably doesn't need to include anything SCRAM specific. However, I
> don't see anything stopping other future channel bindings from mixing
> in data from a specific auth mechanism (eg. to prevent substitution
> attacks when credentials are valid for more than one identity). If we
> forbid servers from advertising different channel binding types for
> different mechanisms, we would not be able to support future mechanisms
> that work this way.
I don't see why anyone would ever want design a SASL mechanism specific
channel binding type. I am happy to learn about potential reasons, of
course. But even if such a channel binding type existed, then the
<sasl-channel-binding/> extension of the <mechanism/> stream feature
shown above would enable clients to deal with it.
- Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
