Re: WG Last Call: draft-ietf-sasl-scram-02

[Chris Newman <Chris.Newman@xxxxxxx>]

--On July 27, 2009 10:48:46 -0400 Jeffrey Hutzelman <jhutz@xxxxxxx> wrote:
> > I am unsure how difficult it will be to add channel binding
> > support to NSS. In the event I succeed with channel bindings, but
> > subsequently experience interoperability problems with channel bindings,
> > I will remove all channel binding support from my implementation.
>
> What this tells me is that you don't consider this an important feature.
> That's unfortunate, because I consider security to be a very important
> feature, and if implementors won't commit to implementing a security
> feature, we have no chance of getting operators and users to actually use
> it.

I consider TLS channel bindings very important, so much so I'm willing to 
invest significant effort attempting an implementation.  But there are 
three directions typical deployments could go here: 1. most people use 
"PLAIN+TLS", 2. SCRAM+TLS-no-channel-bindings gets deployed, 3. 
SCRAM+TLS-with-channel-bindings gets deployed.  If the attempt at 3 is 
non-interoperable, then 1 will be the result as people will associate 
"SCRAM" with "doesn't work".  I strongly prefer option 2 to 1 and will act 
accordingly.  All this talk of channel binding negotiation is leading in 
the direction of non-interoperability and is risking the possibility of 
success with option 3.  I am stating up front that I'll fight for option 2 
if option 3 looks like it will fail.  It's exactly because I care about 
actually getting security deployed that I'm willing to lose the channel 
binding feature if necessary to get an incremental improvement.

Now that you've goaded me to explain my concern.  I'll make a concrete 
suggestion to improve the SCRAM channel bindings section.  I suggest we 
replace this text:

  Clients SHOULD choose the tls-unique channel binding type.
  Conversely, clients MAY choose a different channel binding type based
  on user input, configuration, or a future, as-yet undefined channel
  binding type negotiation protocol.  Servers MUST choose the channel
  binding type indicated by the client, if they support it.

with:

  Clients MUST use the tls-unique channel binding type if a TLS channel is
  active when SCRAM is used.  Clients MAY use a different channel binding 
type if
  an as-yet undefined channel binding type negotiation has confirmed the 
server
  supports the channel-binding type the client selects.

This way, SCRAM+TLS-channel-bindings will interoperate.  With the current 
vague text, it's possible for a compliant client's SCRAM implementation to 
fail to interoperate when communicating with a compliant server's SCRAM + 
TLS-channel-bindings implementation.

		- Chris