Subject: Choice of channel binding types in SCRAM

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 16 Apr 2009 09:15:00 -0700

The selection of channel binding in SCRAM is client choice.  A client  
may for various reasons be unwilling or unable to produce a end-point  
channel binding.  A client ought to always use a unique channel  
binding type and, server willing, bind to the channel, and a server  
which willing to accept an end-point binding ought to willing to  
accept a unique channel binding instead.  If this is not the case, it  
would to create a very brittle system.

Client developers generally like keep things simple.  Adding support  
for end-point types could be viewed by the client developer as an  
unnecessary complication.  It seems likely that client developers  
would simply not code support for end-point types.

Of course, some client developers might see some value in supporting  
end-point types and implement support for them.

By definition, a end-point binding is to be securely bound to the  
channel.  There have been some interesting discussions on and off list  
concerning the implications of self-signed certificates.  It was  
suggested that establishment of the end-point binding might involve  
user interfaces and this has some significant implications.

As a server developer, while I am somewhat concern that client  
developers won't well implement end-point channel bindings, I would be  
quite concerned if the creation of end-point channel bindings ever  
involved user interactions.  Such concerns might lead servers which  
reject end-point bindings.  And that in turn would lead to more client  
developers avoiding use of end-point bindings.

While I understand that end point bindings may be more TLS  
concentrator friendly, but to avoid creating a brittle system, this  
unfriendliness of unique bindings to TLS concentrators must be  
overcome OR we need to remove them from consideration.

In short, at present, I think I favor allowing only unique channel  
bindings in SCRAM.

-- Kurt

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Apr 2009 12:06:31 -0500

> would to create a very brittle system.

The client ought to always be able to use one type in particular or else
another.  And so far we'd been working with "tls-server-end-point" as
the preference.

> In short, at present, I think I favor allowing only unique channel  

Support for concentrators is crucial to deployment.  I don't see how we
can ignore concentrators.

If you were to propose adding the channel binding types to the mechanism
names (well, suitably compressed to fit in the 20 char SASL mech name
limit), I could go along with that.  Giving up on concentrators is just
not an option without first hearing from concentrator implementors
(also, I'm pretty sure that Chris would object).

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 16 Apr 2009 12:55:32 -0700

On Apr 16, 2009, at 10:06 AM, Nicolas Williams wrote:
> limit), I could go along with that.

While not a perfect solution (I don't think a perfect solution  
exists), I willing to go along with this... as I can simply ignore the  
end-point variant.

-- Kurt

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Apr 2009 15:05:36 -0500

> exists), I willing to go along with this... as I can simply ignore the  

Another possibility is to have a pair of magic mechanism names to
negotiate the use of one or another channel binding type independently
of mechanism name, with reasonable defaults for when these are missing
from the server's mech list.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 17 Apr 2009 00:39:36 +0200

> exists), I willing to go along with this... as I can simply ignore the

That would work for me as well.  I don't see any reason to implement the
tls-server-end-point channel binding as it only works with X.509 server
certs whereas tls-unique always works.  I share Kurt's concern that
these channel binding trade-offs may make the system brittle.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Apr 2009 06:34:54 +0100

Simon Josefsson wrote:

>certs whereas tls-unique always works.
>
>I share Kurt's concern that
+1