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