Re: Negotiating the SCRAM channel binding type

On 12/07/18 16:08, Michael Paquier wrote:
> On Thu, Jul 12, 2018 at 12:34:51PM +0300, Heikki Linnakangas wrote:
>> Hmm. That is actually in a section called "Default Channel Binding". And the
>> first paragraph says "A default channel binding type agreement process for
>> all SASL application protocols that do not provide their own channel binding
>> type agreement is provided as follows". Given that, it's not entirely clear
>> to me if the requirement to support tls-unique is for all implementations of
>> SCRAM, or only those applications that don't provide their own channel
>> binding type agreement.
> 
> I am not sure, but I get that as tls-unique must be the default if
> available, so if it is technically possible to have it we should have it
> in priority.  If not, then a channel binding type which is supported by
> both the server and the client can be chosen.

Another interesting piece of legalese is in RFC 5929 Channel Bindings 
for TLS:

>    For many applications, there may be two or more potentially
>    applicable TLS channel binding types.  Existing security frameworks
>    (such as the GSS-API [RFC2743] or the SASL [RFC4422] GS2 framework
>    [RFC5801]) and security mechanisms generally do not support
>    negotiation of channel binding types.  Therefore, application peers
>    need to agree a priori as to what channel binding type to use (or
>    agree to rules for deciding what channel binding type to use).
> 
>    The specifics of whether and how to negotiate channel binding types
>    are beyond the scope of this document.  However, it is RECOMMENDED
>    that application protocols making use of TLS channel bindings, use
>    'tls-unique' exclusively, except, perhaps, where server-side proxies
>    are common in deployments of an application protocol.  In the latter
>    case an application protocol MAY specify that 'tls-server-end-point'
>    channel bindings must be used when available, with 'tls-unique' being
>    used when 'tls-server-end-point' channel bindings are not available.
>    Alternatively, the application may negotiate which channel binding
>    type to use, or may make the choice of channel binding type
>    configurable.

In any case, I'm quite convinced now that we should just remove 
tls-unique, and stick to tls-server-end-point. Patch attached, please 
take a look.

- Heikki