[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 02:47:39PM -0700, Kurt Zeilenga wrote:
> 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.
Can you elaborate on how our approach might do that? I don't see it,
but perhaps I'm biased.
> 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.
The current proposal is designed precisely to make all three of the cb
type negotiation schemes proposed thus far feasible:
- your and Simon's N*M proposals
- Jeff's pseudo-mechanism to negotiate cb type
- my N+M proposal
I don't see how our proposal precludes any one of them.
(I also don't see how my N+M proposal makes it difficult or impossible
to have mechanisms like YAP. I've posted an algorithm that shows how it
does, in fact, allow for YAP. But I don't want to get into that
discussion. I want to stop at: does our concrete proposal allow or
preclude any of the proposed, future cb type negotiation schemes? I
believe the answer is that it allows all of them and precludes none.)
> So long as SCRAM and GW are adequately extensible, this shouldn't be a
That's the point of our proposal.