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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Chris Newman <Chris.Newman@xxxxxxx> writes:

> 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.

FWIW, I largely share your concern.  I may be more hopeful about getting
3 to work in practice though, technically it seems easy to implement.

> 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.

I'm not sure this change is good -- first, the MUST is clearly violated
when the MAY-path is exercised, so it is not internally consistent.
This was one of the motivations for SHOULD, IIRC, although I agree that
it wasn't completely clear before either.  Also you dropped the last
sentence which is necessary to get interoperability.  How about:

   Clients MUST use the tls-unique channel binding type if a TLS channel
   is active when SCRAM is used, or 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.  Servers MUST choose the channel binding type indicated by
   the client, if they support it.

?

/Simon