[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Poll: use of TLS channel bindings in SCRAM
On Fri, May 29, 2009 at 03:08:13PM -0700, Kurt Zeilenga wrote:
>
> 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.
Our proposal does not preclude that for mechanisms other than SCRAM
(since it doesn't need that ability) or other than GS2 (since GSS-API
mechanisms shouldn't be like YAP).
And for SCRAM/GS2 it will allow what you want *when* we add channel
binding type negotiation, but that negotiation will have to be done
outside SCRAM/GS2 (as in, for example, your N*M proposal).
My N+M scheme has the same feature. BUT AGAIN, we don't need to discuss
it!
> >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.
You must do better than that. You must review the proposal and tell us
whether it meets your requirement, NOT keep sending e-mails arguing
other things that we're all trying to avoid, and which wastes enormous
amounts of my and others' time. Respect my time, review the proposal.
Nico
--