Subject: summary of SCRAM TLS channel binding discussion

From: Tom Yu <[email-masked]>
Date: Mon, 06 Jul 2009 23:22:17 -0400

Having reviewed a large quantity of mailing list traffic, I will
attempt to summarize the outcome of this discussion (which spans more
than one hundred messages).  Please let me know if I appear to have
misrepresented anything.  I intend to restart the WG Last Call on
SCRAM (and start one on GS2) this week unless the authors feel that
the current versions are not ready.

There appears to be consensus around option 1a (using Alexey's
labeling): SCRAM will use a single allowed TLS channel binding type,
which is tls-unique, deferring the ability of negotiating channel
binding types.

In addition, some participants, including Nico Williams, Simon
Josefsson, Sam Hartman, and Jeff Hutzelman, worked to come up with a
compromise proposal for GS2 and SCRAM for providing a method for a
client to declare to a server what channel binding it is using, while
not committing to any specific negotiation method for channel binding
types.  There appears to be rough consensus around this proposal.

I will note that there appears to be consensus that SCRAM (and GS2)
should move forward as quickly as reasonably possible.  While there
may continue to be disagreement about the form that the negotiation
method for channel binding types will take, there appears to be rough
consensus that the current proposal for a client to declare a channel
binding does not preclude the existence of some future method for
negotiating channel binding types.  Additionally, there appears to be
consensus to defer any decision about the details of negotiating
channel binding types so that SCRAM may proceed without additional
hindrance.

As a means of realizing the working group consensus that SCRAM proceed
as quickly as reasonably possible, I strongly recommend that until we
conclude our work on the SCRAM document, any future debate about
methods of negotiating channel binding types concentrate on whether
there are specific and concrete reasons, grounded in plausible
implementation or deployment concerns, why the compromise proposal is
harmful.

                         ====================

The original poll as posted by Alexey:

    1). SCRAM should just use a single allowed TLS channel binding and
    don't have any negotiation of other TLS channel bindings (*) (**)
    a). the default is tls-unique
    b). the default is tls-server-end-point
    2). SCRAM should just use tls-server-end-point, fallback to
    tls-unique, no negotiation of other TLS channel bindings (*)
    3). SCRAM should always use channel binding negotiation (*)
    4). SCRAM should have a default TLS channel binding with optional
    negotiation of TLS channel bindings (*)
    a). the default is tls-unique
    b). the default is
    5). I have another opinion [this is for the case when there is some
    valid choice which you think should be considered by the WG]

    Notes:
    (*) - whether such negotiation happens inside or outside of SCRAM
    (**) - channel binding negotiation can be added later on

I have assumed, as have some participants, that the missing phrase in
option 4b is "tls-server-end-point".  The following text is a very
rough and incomplete summary of some individual opinions.

Jeff Hutzelman and others strongly oppose any technique that involves
registrations of N * M composed mechanism and channel binding type
names.

Simon preferred explicit registration of specific combinations,
believing that the subset of N * M with desirable security properties
is limited.

Kurt wants to ensure that any changes to GS2 or SCRAM in the area of
channel bindings do not unreasonably constrain the design of any
future SASL mechanism.  He particularly wants to avoid strategies that
could preclude purely in-mechanism channel binding type negotiation,
or make them difficult to specify or implement.  Kurt appears to
prefer a means of negotiating channel binding type by including the
name of the channel binding type in the mechanism name.

-- 
Tom Yu
IETF SASL WG co-chair