On Sun, May 10, 2020, at 10:34, Florian Schmaus wrote: > "Look, they did the same bad thing here, then it must be OK if I do > the same", is no argument.
Why is it bad? That is what I'm asking. You're starting from the point that "-PLUS" or "-tls-unique" are bad somehow, I am arguing that they're not. So far no one has told me what they think is actually wrong with it (with the exception that you mentioned that you think the list could be long, which I'll address in just a moment), they've just proposed alternative solutions with no indication of what is wrong with the one I proposed. > It (1) unnecessarily bloats the SASL mechanism space with (2) > unregistered mechanisms while (3) additionally adding a lot of > redundant information. Why is this a problem? At most it's 4 or 5 extra mechanisms. It is never going to be enough data to cause a problem as far as I can tell. > 2: All those mechanisms do not, and very likely will never, appear in > the IANA SASL mechanism registry. Yes, the spec specifically says that they shouldn't. I also don't see a problem with this, they are specific to this spec and XMPP and don't need to be listed everywhere. Not listing them also doesn't create an incompatibility with anything else. > 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. As I explained in my previous email, we can't assume that. > Even if there is a channel binding type that is specific to a SASL > mechanism, then the server announcing … 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. Ah yah, you're right about this, it just moves the burden of knowing what mechanisms can use what channel binding types from the server to the client. I think this is fine. > 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. I briefly mentioned one reason why you might want to in the paragraph you're replying to. However, I'll try and come up with a more concrete example (though with the disclaimer that this will necessarily be somewhat contrived): Imagine that we're on a corporate network that MITMs all TLS connections with one of those proxies that requires that you install a root cert on your machine. Traditional channel binding like tls-unique is designed to cause auth to fail in a case like this because the client and the server see a different TLS connection. This is good! However, we may still want to use XMPP on this server so we design a new SASL mechanism that negotiates its own security layer inside of the TLS layer (something SASL mechanisms are allowed to do). We want this new mechanism to support channel binding, so we use the tls-unique data from the SASL negotiated security layer. However, we also want auth to fail if the connection to our corporate firewall has been reset and is now pointing at a malicious actors machine on the same network, so we mix in the original tls-unique data as well. This is now a new channel binding type that is specific to our auth mechanism. Like I said, I know this example is incredibly contrived, but we can't predict what sort of auth mechanisms we'll have in the future, and this doesn't seem so incredibly unlikely that we shouldn't consider it. —Sam -- Sam Whited _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
