On Wed, Jul 11, 2018 at 12:27:33PM +0300, Heikki Linnakangas wrote:
> as the supported mechanisms, we change that into:
>
> SCRAM-SHA-256-PLUS tls-unique
> SCRAM-SHA-256-PLUS tls-server-end-point
> SCRAM-SHA-256
Can we say for sure that there won't be other options associated to a
given SASL mechanism? It seems to me that something like the following
is better long-term, with channel binding available as a comma-separated
list of items:
SCRAM-SHA-256-PLUS channel_bindings=tls-unique,tls-server-end-point
SCRAM-SHA-256
> Thoughts? Unfortunately this breaks compatibility with current v11beta
> clients, but IMHO we must fix this. If we want to alleviate that, and save a
> few bytes of network traffic, we could decide that plain
> "SCRAM-SHA-256-PLUS" implies tls-unique, so the list would be:
>
> SCRAM-SHA-256-PLUS
> SCRAM-SHA-256-PLUS tls-server-end-point
> SCRAM-SHA-256
>
> That would be mostly compatible with current libpq clients.
I am not sure it is worth caring about the compatibility at a beta2
stage, as v11 is not released yet. Still I agree that not specifying
anything should mean the default, which is per the RFCs currently
existing tls-unique.
Another piece of the puzzle is here as well:
https://www.postgresql.org/message-id/flat/20180122072936.GB1772@paquier.xyz
We need to allow a given SSL implementation to specify what the list of
channel bindings it supports is.
--
Michael
