[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Poll: use of TLS channel bindings in SCRAM
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
What I don't find acceptable is any assumption that applicability
particular channel binding type is the same for all mechanisms used
within a particular application layer protocol. Hence, I want
negotiation which allows the server to say which channel binding
willing 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
and 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
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
can 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
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
levels 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