--On Friday, May 29, 2009 11:13:47 PM +0200 Simon Josefsson <simon@xxxxxxxxxxxxx> wrote:
I think there is something critically missing from this elaboration: Even though there can be theoretically up to 36 names, or possibly hundreds, or thousands, I believe that does not matter in practice. In practice, for any particular server, only a few set of combinations will be useful. The set of practically useful combinations are much more limited than the N*M figure suggests.
That's true. This means that if we can make the N*M registration problem go away, then the n*m negotiation problem may actually be tractable.
There is a one step in getting a combination of a SASL mechanism and a channel binding type approved: the IANA allocation of the SCRAM-CB-FOO name.
Too hard. Users shouldn't have to do that; they shouldn't have to have even heard of IANA. Inventing a new CB type shouldn't involve enumerating all of the existing mechanisms and registering new names; the CB type designer may not even know what SASL is. Inventing a new mechanism shouldn't involve enumerating all of the existing CB types, either.
it makes us have to think about the security properties of each particular combination of mechanism with channel binding. We have already seen that YAP have different properties than SCRAM when used with tls-server-end-point. That can be true generally. It seems like a mistake to not think about each particular combination.
The more I think about this, the more I believe this is because YAP's handling of channel bindings is fundamentally broken. Channel bindings are supposed to be opaque to the mechanism that carries them; the security properties of a mechanism should not depend on channel bindings, and they should not affect the security properties of channel bindings, let alone the channel itself.
A much better strategy is the manual registration step I mentioned above.
No, that's not better. It doesn't scale. It requires coordination and binding between components that should be orthogonal and independent.
In any case, I strongly prefer that GS2 and SCRAM not lock us into a particular negotiation model, and instead allow the flexibility to choose from among a variety of models later, if/when we determine thet negotiation is actually needed, and in the meantime allow users and SASL application protocol designers the flexibility to choose the meechanisms and channel binding types they need.Hear, hear.
And so, at least for now, I think I'm going to give up on this aspect of the discussion as well. I don't think we're going to converge soon, and for the moment, I don't think trying is worth our collective time and effort.
-- Jeff