Re: Poll: use of TLS channel bindings in SCRAM

[Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx>]

On May 30, 2009, at 8:49 AM, Jeffrey Hutzelman wrote:
> At the moment, I cannot think of anything that could be accomplished  
> using a multi-level scheme that could not be done using at least one  
> of your M*N mechanism scheme, Nico's M+N independent-negotiation  
> scheme, or my negotiation pseudo-mechanism scheme.  Can you?

Your scheme is interesting in that it could be viewed as a multi-level  
negotiation scheme.  A more interesting question with regard to it  
might be whether the interoperability problems found in in-the- 
mechanism negotiation schemes can be avoided within your scheme.

So long as the client is allowed in the pseudo-mechanism exchange to  
select any mechanism, including possibly ones not advertised as part  
of the pseudo-mechanism exchange or the application-level mechanism  
advertisement, then I think the interoperability problems found in  
multiple-level negotiation schemes can be avoided in this scheme.   
However, if one restricts the choice of mechanism in the pseudo- 
mechanism exchange to only those listed in the pseudo-mechanism, the  
scheme would suffer the interoperability problems we seen with in-the- 
mechanism multi-level negotiation schemes.

But to respond directly to your question, at present, I cannot think  
of anything that cannot be accomplished by multi-level scheme that  
cannot be accomplished by one schemes you listed.  However, certainly  
some listed schemes cannot accomplish everything that could be done in  
a multi-level scheme.  For instance, Nico's scheme doesn't accomplish  
per-mechanism negotiation of channel binding types.  And your scheme  
doesn't accomplish negotiation without introduction of any additional  
round trips, and various other schemes suffer other problems not found  
in an in-the-mechanism negation approach.  But with this noted, I  
might support a proposal which precludes (or significantly hinders) an  
in-the-mechanism negotiation approach.  I have a couple of other  
concerns to think through before I revise my stand (do not take my  
"might support" as a "do support") on the poll and various proposals.

> I agree that we should defer attempting to reach a consensus on a  
> negotiation solution.  I think at some point that means we stop  
> talking about it, because if we don't, aren't we still trying?

> That said, I don't think we need to stop talking about it NOW until  
> we finish SCRAM/GS2, as long as we treat it as a mostly-independent  
> discussion and not something that blocks those documents.  I _think_  
> we've mostly been doing that, except for the multi-level issue above.

I think we basically agree here.  It's a matter of objectives of the  
discussions.   At present, I see the primary objective as reaching  
consensus on text of the SCRAM and GS2 I-Ds.  Other issues are  
secondary.  I and others would be ecstatic if in addressing the  
primary objective we also resolved secondary objectives.  So while I  
continue to think it good to defer attempts to reach consensus on a  
negotiation solution, I'm don't object to discussions of solutions so  
long as these discussions do not unduly impede our ability to reach  
consensus on SCRAM and GS2 I-Ds.

-- Kurt