[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Poll: use of TLS channel bindings in SCRAM




--On Friday, May 29, 2009 02:47:39 PM -0700 Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx> wrote:


On May 29, 2009, at 1:49 PM, Jeffrey Hutzelman wrote:


--On Friday, May 29, 2009 01:02:53 PM -0700 Kurt Zeilenga
<Kurt.Zeilenga@xxxxxxxxx
> 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.

Yup, I think we all understand that; we just don't all agree with
it, or think it's compelling enough to override the M*N concern.
However, the beauty of the current proposal is that it doesn't
require us to select a negotiation strategy now; instead it gives
us, or application protocol designers, or users, the flexiblity to
select from among a variety of strategies.

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.

You mean, a strategy in which each mechanism is responsible for managing negotiation of channel binding types, and we don't get to do that negotiation until after we've selected a mechanism?

It does preclude it for GS2/SCRAM, short of modifying the mechanism, but I don't think there's anything we can do about that if we want to finish those mechanisms any time soon. I don't think it precludes it for other mechanisms.

However, I also don't think it matters, because I believe we're all in agreement that multi-level negotation brings nothing but trouble and should be ignored.


While I dislike multiple levels of negotiation, I would rather have
multiple levels of negotiation than channel binding type negotiation
which is not done on a per mechanism basis.

So, you'd rather pick YAP and then discover that only tls-unique is supported but you can't use a unique binding for your TLS session (and thus authentication fails) than be able to detect this situation in advannce and fall back to SCRAM?

Multi-level negotiation is a bad idea. We know this is true. We have numerous examples of why it is true. I see no reason to go out of our way to allow for it here when we have a variety of negotiation strategies to choose from that are not multi-level, and there is nothing you get from a multi-level strategy that cannot be obtained from the others, aside from a major interoperability headache.

Letting each mechanism decide how to negotiate CB is also a bad idea. It's not up to the mechanism what channel to use, or how to describe it. That's a massive violation of modularity. I've been trying to explain that to you for months now. I've been trying to explain why modularity is important for months now. Apparently I have utterly failed. I cannot understand how you can be so active in the development of SASL and not understand the importance of the concept that is SASL's entire reason for existance.

-- Jeff