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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

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

Right.

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

That is what I meant too.

> I'll be happy to see this SHOULD turn into a MUST.

The last sentence still seems necessary though.  So the paragraph
becomes:

  Clients MUST choose the tls-unique channel binding type.  Servers MUST
  choose the channel binding type indicated by the client, if they
  support it.

I suspect we want SCRAM and GS2 to be consistent on this, right?  So
both documents needs this change.

/Simon