From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Negotiating the SCRAM channel binding type |
Date: | 2018-07-20 17:05:04 |
Message-ID: | c35f9f3e-a831-715e-2517-689152c27202@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
0001-Remove-support-for-tls-unique-channel-binding.patch | text/x-patch | 37.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-07-20 18:11:24 | Re: [WIP] [B-Tree] Retail IndexTuple deletion |
Previous Message | Andres Freund | 2018-07-20 16:45:10 | Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM) |