On May 29, 2009, at 1:49 PM, Jeffrey Hutzelman wrote:
--On Friday, May 29, 2009 01:02:53 PM -0700 Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx > wrote:What I don't find acceptable is any assumption that applicability of anyparticular channel binding type is the same for all mechanisms used within a particular application layer protocol. Hence, I wantnegotiation which allows the server to say which channel binding types itwilling to support on a per mechanism basis.Yup, I think we all understand that; we just don't all agree with it, or think it's compelling enough to override the M*N concern. However, the beauty of the current proposal is that it doesn't require us to select a negotiation strategy now; instead it gives us, or application protocol designers, or users, the flexiblity to select from among a variety of strategies.
I am a bit concerned that that current proposal might preclude certain negotiation strategies from consideration as they would be difficult to retrofit in. In particular, I am concerned that the current proposal might preclude purely in-the-mechanism-exchange negotiation of channel binding types.
As for as the N*M problem, I think N and M are relatively small numbersand hence N*M doesn't concern me significantly.Yeah, the problem is that you believe that N and M are small numbers today, and assume that therefore they always will be. Let's look at that assumption...
I note that since not all channel binding types are applicable to every which supports channel bindings, the total possible mechanisms that could be advertised is less than N*(M+1).
And as I would design it, only N+(M+1) would need to be registered (assuming every type was used in every mechanism): N in the SASL table, M+1 in the channel binding type.
Also, I don't this as creating an N*M registration issue. N and M valuescan be registered separately.Right up until the point where you realize that SASL allows N names to be up to 20 characters long, and RFC5056 places _no_ limit on names (but the existing registrations are 10, 20, and 21 characters long), and yet SASL application protocols may only allow for mechanism names up to 20 characters long, because SASL says they won't be any longer.
And if you advertise the channel binding types as a mechanisms, presumedly prefixed with some short string so as to reserve a portion of the SASL name space for channel binding types, you are also going to run into 20 character problem.
For instance, C-TLS-SERVER-END-POINT is too long. And even without a prefix, there's the RFC 5056 no limit problem.
I suppose you could hash both the SASL mech name and channel binding name, and come up with a combined string that's not longer than 20 characters, but then you will get pushback from the same people who complained about hash-based names in GS2.
Yes, but my solution is not the only one which suffers from this problem.
Weren't you one of those?
I recall supporting "meaningful" names for SCRAM. For GS2, I don't care all that much (except for how it impacts SCRAM).
Though I dislike multiple levels of negotiation, I rather have multiplelevels of negotiation which was not per mechanism.I'm afraid I can't parse this. Can you try again?
While I dislike multiple levels of negotiation, I would rather have multiple levels of negotiation than channel binding type negotiation which is not done on a per mechanism basis.
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.
I would like SCRAM and GS2 not to preclude a particular negotiation model, including per-mechanism negotiation approaches such as what I propose and/or in-the-mechanism negotiation.
So long as SCRAM and GW are adequately extensible, this shouldn't be a problem.
-- Kurt