[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 05:00:31PM -0700, Kurt Zeilenga wrote:
> From my initial review of your proposal:
> 
> 1) Jeffrey's message  
> <2C640B3F7470041AD6A981CB@xxxxxxxxxxxxxxxxxxxxxx>) suggests your  
> proposal does preclude in-the-mechanism negotiation.  However, I  
> wonder if the SCRAM extension mechanism could be used to provide  
> such.  Your assessment of the possibility to subsequently extend SCRAM  
> and GS2 to support in-the-the mechanism exchange negotiation would be  
> of interest to me.  I think debate over the suitability of such  
> negotiation could be deferred.

It does not preclude in-the-mechanism negotiation, but SCRAM and GS2
will never do that.

You're still not addressing the issue that I believe you must address.
I believe that your primary goal here is to make YAP feasible, so I'm
going to ask point blank:

1) Am I correct to believe that your one requirement is that we do not
   preclude YAP?

   If so, please stop distracting us with in-the-mechanism negotiation
   and what not and instead answer the next question.  If not then
   please state your requirements clearly, then we can have a separate
   poll on the question of whether we should meet those.

   (I think we're not so opposed to YAP that we'd want to preclude it,
   thus we probably don't need a poll on the question of whether we
   should avoid precluding YAP.)

2) Does our proposal preclude YAP?

> 2) it appears to hinder the subsequent adoption of the negotiation  
> solution as it uses SCRAM mechanism names to select whether channel  
> binding is to be used or not instead of for channeling binding is to  
> be used, and if which, or not.  That is, it registers a -PLUS  
> mechanism.  My solution has no use or need for a -PLUS mechanism, but  
> I'd be forced to deal with the existence of the -PLUS mechanism and  
> hence placing the subsequent adoption of my solution at disadvantage  
> albeit quite a minor one.

Our proposal does fit your N*M scheme: The -PLUS mechanism names
correspond to the -TLS-UNIQUE mechanism names in your scheme.

Nico
--