Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

[Responding slightly out of order.]

On Sat, May 30, 2009 at 09:26:22AM -0700, Kurt Zeilenga wrote:
> Well, while I would agree that your proposal doesn't preclude my  
> approach, I wouldn't say it "only defers the addition ...".  I do  
> think your proposal does place my approach at a slight disadvantage in  
> subsequent engineering discussions.  To illustrate this point,  
> consider whether you would agree to changing SCRAM-*-PLUS to SCRAM-*- 
> TLS-END-POINT now.  I suspect you would object to this, because the  
> negotiation solutions you favor would no need for this.  But likewise,  
> my negotiation approach has no need for SCRAM-*-PLUS.

This is an argument about aesthetics, not a technical argument.

> But as I noted in my comments, I consider this to be quite a minor  
> disadvantage.  While I certainly will consider this impact, I don't  
> think it will be a major deciding factor on what stand I take in the  
> end.

Given what you say I think it'd be quite reasonable to conclude that
you're on the rough side of consensus, as you say.

> On May 29, 2009, at 10:29 PM, Nicolas Williams wrote:
> >Kurt has not told us where he stands on our proposal.
> 
> While I have stated a number of concerns, but in general and  
> specifically in response to your proposal, I have yet decided whether  
> I support your proposal.  As I noted in Jeffrey's message, I am  
> currently considering the impacts of your proposal on possible  
> negotiation solutions.  I do plan on making a stand before the poll  
> expires.

By the way, I think you've convinced me that your concerns derive from
the YAP's violation of the channel binding abstraction, and that
therefore we need to consider the possibility that YAP is harmful.

To that end I've been thinking about the possible ways in which weak
mechanisms and weak channel binding types can combine to create weaker
combinations such that one might then want per-mechanism policy w.r.t.
channel binding type.  I've thought up some interesting such mechanisms
and channel binding types (some with Sam's help), but so far the worst
weaknesses of such combinations are easily worked around by, for
example, requiring the use of confidentiality protection in the
underlying channel (somthing which, incidentally, password-based
mechanisms like SCRAM and YAP need anyways to protect against off-line
dictionary attacks).

My tentative conclusion so far is that YAP is more trouble than it's
worth, and that the IESG would do well to consider requesting that the
RFC-Editor not publish any RFC, even experimental, describing mechanisms
like YAP.  But that conclusion does not stem so much from the weaknesses
of YAP+<imagined weak channel binding types> as those seem far from
fatal so far, but from the complexity that YAP adds to discussions of
channel binding type negotiation.

I don't worship at the altar of round-trip reduction so much that I'm
willing to deal with abstraction violations that so complicate other
work, though clearly I'm willing to seek round-trip reductions in
general (see, for example, draft-williams-tls-app-sasl-opt-03).  And
the funny thing is that YAP is particularly intended as a round-trip
optimization on TLS, to provide privacy protection to the client
identity with only one round-trip beyond the TLS handshake (well, TLS +
SASL mech nego, + YAP half-round-trip + the SASL outome of auth
message), but draft-williams-tls-app-sasl-opt-03 would result in
TLS+SASL/SCRAM having the same number of round-trips!  Now,
draft-williams-tls-app-sasl-opt-03, like YAP, does something that one
might consider bad, but the former strikes me as much more acceptable
than the latter.

Nico
--