Re: Poll: use of TLS channel bindings in SCRAM

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

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  
> problem.

That's the point of our proposal.