[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:47 PM, Nicolas Williams wrote:


On Fri, May 29, 2009 at 01:02:53PM -0700, Kurt Zeilenga wrote:
What I don't find acceptable is any assumption that applicability of
any 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 types
it willing to support on a per mechanism basis.

My M+N negotiation scheme does NOT make "any assumption that
applicability of any particular channel binding type is the same for all
mechanisms..."

I guess I should clarify, what I want is the ability for implementors and deployers to choose which binding types they support on a per mechanism basis.

It does, however, require local knowledge of the applicability of any
server-advertised, client-supported channel binding type to any server-
advertised, client-supported SASL mechanism.  And it requires applying
that knowledge via a simple (but by no means trivial) algorithm.

The problem I see is that what the server developer/implementor thinks is applicable may be quite different from what the client developer/ implementor thinks is applicable.


BUT, the point of Jeff's and my proposal is this: we don't need to argue
about the merits of M*M, M+N, or a pseudo-mechanism to negotiate cb
types -- we can stop at making it possible to add a secure cb type
negotiation later.

By deferring discussion of a feature where we don't have consensus
(multiple proposals, each with their set of problems, and their
champions) to when we ever end up needing it, we make it easier to reach
consensus _now_ on the minimum that we need to get SCRAM/GS2 out the
door.

If you don't agree with this approach to reaching consensus, please say
so.


I am fine with this approach so long as what we do and say now doesn't preclude, hinder, or disadvantage any of the obvious and/or suggested (though possibly not broadly supported) negotiation solutions from being subsequent chosen as the solution.

I'll comment on this later.

-- Kurt