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

Re: Poll: use of TLS channel bindings in SCRAM




--On Saturday, May 30, 2009 08:06:41 AM -0700 Kurt Zeilenga <Kurt.Zeilenga@xxxxxxxxx> wrote:


On May 29, 2009, at 10:46 PM, Jeffrey Hutzelman wrote:
Have you missed that part?

We're NOT TRYING TO DECIDE HOW NEGOTIATION SHOULD WORK.

Yes, but we are trying to decide what SCRAM I-D says about channel
bindings.  I have tried to point out that what the SCRAM I-D says about
channel bindings have an impact upon on possible negotiation solutions,
and hence feel it reasonable to discuss these impacts.


Unfortunately, despite the fact that we've shown that a variety of
approaches can work with GS2 modified as we've described, including
several very different approaches proposed by different people, we
keep finding ourselves arguing about which of those proposals is the
right one instead of finishing the documents that don't depend on
the outcome of that discussion.

I have tried hard not to argue about the suitability of negotiation
approaches, instead trying to focus on how changes we might make in the
SCRAM I-D might impact possible solutions.  However, at times it might
well be appropriate to discuss the suitability of possible solutions in
order to reach consensus on what changes we make to SCRAM.

I believe we all understand that multi-level negotiation is a bad
idea.

And this is a case in point.  When I raised concerned that the proposal
seemed to preclude a particular possible solution, I think it quite
reasonable for you and others to engage me in questions of the
suitability of such a solution, so that we can determine whether this is
something we think is "okay" to preclude (or hinder or disadvantage).

OK, so let's talk about that. I believe that we all think multi-level negotiation is a bad idea, and want to avoid it if possible. So then the question becomes, given the current proposed changes to GS2/SCRAM, is there some desirable we could achieve via a multi-level negotiation scheme that could _not_ be accomplished using one or more of the other schemes?

If no such goal exists, then we should be able to easily reach consensus that it is OK to preclude such approaches.

If there is such a goal, then we need to consider whether that goal can be achieved by some change to one of the other schemes or by inventing some new scheme, and/or whether the goal is so important that it is worth the trouble that multi-level negotiation causes _and_ worth the time and effort of holding up GS2 and SCRAM to make multi-level negotation possible.


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?



I am more making sure we consider now the impacts of what we do now on
our subsequent work to develop a negotiation solution.  This naturally
involves some discussion of possible negotiation solutions.  In my
opinion, we should defer attempting to reach consensus on a negotiation
solution, however we should continue to discuss possible negotiation
solutions, especially in the context of how proposed changes to SCRAM and
GS2 impact possible negotiation solutions.

I think the multi-level issue discussed above is the only one currently open that materially affects SCRAM and GS2. So we certainly should resolve that.

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.


Why in the world would you want to hold up a document because it
doesn't allow for doing something that no one wants to do anyway?

I'm trying to understand all the impacts of the proposals for this
document, so that I can decide whether which of the proposals I might
support.  I am not trying to hold up the document.  The poll doesn't
expire until the 7th.  I am sure I will be able to decide before the
conclusion of the poll as which proposals I support.  It may well that
I'll end up being in the rough.

So, the poll isn't really proposals so much as a taxonomy of the choices that Nico and Alexey could think of. It really offers a couple of questions...

- Should negotiation be (1) added later, (2) added never,
 (3) added now and mandatory, (4) added now and optional
- If there is a need for a default, should it be unique or endpoint or...?

Depending on your interpretation, Alexey's (2) could really be (1c); allowing for the possibility of future negotiation but making the default be a fallback model.

I think it highly unlikely at this point that the answer to the second question will be anything other than "tls-unique". But it doesn't much affect any of the other issues.

I believe we have all agreed that we don't want to preclude the possibility of adding negotiation later, if we don't do it now.

I believe there is only one actual proposal on the table, which is to modify the definition of GS2 and SCRAM to carry information about which CB type was used, if CB is used, and about which CB types the client supports, if the client supports CB but believes it has no type in common with the server (that's about preventing downgrades; the only decision the server is intended to use it for is to fail authentication if the client lists a type that the server actually _does_ support).

The point of this proposal is to make irrelevant the question of whether we add negotiation now, later, or not at all, and of how the negotiation works (an issue the poll deliberately avoided), by agreeing that negotiation must happen outside the mechanism (which is not the same as saying it must not take the mech into account), and insuring that GS2/SCRAM provides the needed protocol slot to carry the results of that negotiation.


BTW, I believe it's very much appropriate to wait until the poll expires before doing anything. However, I don't think that means we can't build a consensus before then on exactly what to do to GS2/SCRAM, at which point the outcome of the poll mostly determines whether we continue to discuss negotiation, and if so, whether we WGLC GS2/SCRAM and then sit on them until we have negotiation done, so they can have a mandatory-to-implement reference to the negotiation scheme (option (3) would require that).

-- Jeff