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

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Tue, Jul 28, 2009 at 02:30:39PM +0200, Simon Josefsson wrote:
> Chris Newman <Chris.Newman@xxxxxxx> writes:
> > 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.

We do this all the time in IETF protocols, where we say that one MUST
send 0 in some field that's reserved for future extensions, and we state
how one must react to non-zero values in that field, then later we relax
that and say what values may be sent.  What should happen here is that
the second sentence in Chris' proposed text should just be removed -- a
future update will not be bound to keep the MUST in the first sentence.

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

No, _my_ motivation for that SHOULD was to allow clients and servers to
agree a priori and out of band to use some other CB type than
tls-unique.  I'll be happy to see this SHOULD turn into a MUST.

Nico
--