Re: Poll: use of TLS channel bindings in SCRAM

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

> On Fri, May 29, 2009 at 08:29:42PM +0200, Simon Josefsson wrote:
>>                         ...  The changes can be summarized into:
>> 
>> 1) Add text to say that with 'p' one cb type name is included (normally
>> tls-unique)
>> 
>> 2) Add text to say that with 'y' a list of cb type names supported by
>> the client is included
>
> There is a slightly better way that would simplify the client: define
> new GS2 CB flags to go with the 'n', 'y', and 'p' that we have now
> (which would stay as they have been, w/o any additional GS2 header
> fields).  The three flags we have now:
>
>  - 'n' (client can't do CB)
>  - 'y' (client can only do tls-unique but thinks the server can't do CB)
>  - 'p' (client used CB of the default type)
>
> plus two new ones that today's servers would have to understand but
> today's clients wouldn't have to:
>
>  - 'Y' and a list of CB types in GS2 header (client can do CB and CB
>    type negotiation and thinks the server advertives the given, possibly
>    empty list of CB types)
>
>  - 'P' and a single CB type in GS2 header (client used CB of the given
>    type)
>
> This way the server needs to know about the new bits in GS2 for future
> downgrade protection in the face of CB type nego, but the client doesn't
> have to know anything at all about future CB type nego.
>
> Simplifying the client strikes me as a good thing.

It adds more text to the specification, and some complexity, but it
seems like a reasonable compromise to simplify client implementations.

Before I update GS2 with that, what is the chance of making these
changes to SCRAM?  Alexey?

/Simon