On Sat, May 19, 2018 at 09:35:57PM +0900, Michael Paquier wrote:
> On Fri, May 18, 2018 at 09:30:22AM -0400, Bruce Momjian wrote:
> > Good work, but I think the existance of both scram_channel_binding and
> > channel_binding_mode in libpq is confusing. I am thinking we should
> > have one channel binding parameter that can take values "prefer",
> > "tls-unique", "tls-server-end-point", and "require". I don't see the
> > point to having "none" and "allow" that sslmode supports. "tls-unique"
> > and "tls-server-end-point" would _require_ those channel binding modes;
> > the setting would never be ignored, e.g. if no SSL.
>
> I can see the point you are coming at. Do you think that we should
> worry about users willing to use specifically tls-server-end-point
> (which is something actually in the backend protocol only for JDBC) and
> manage a cluster of both v10 and v11 servers? In this case we assume
> that "prefer" means always using tls-unique as channel binding, but
> there is no way to say "I would prefer channel binding if available,
> only with end-point". It would not be that hard to let the application
> layer on top of libpq handle that complexity with channel binding
> handling, though it makes the life of libpq consumers a bit harder.
This is going to be hard enough so let's do whatever we can to simplify
it.
> Hence, I would actually eliminate "require", as that would be actually
> the same as "tls-unique", and the possibility to use an empty value from
> the list of options available but add "none" as that's actually the same
> as the current empty value. This gives as list:
> - tls-unique
> - tls-server-end-point
> - none
> - prefer, which has the meaning of preferring tls-unique
> - And prefer-end-point? But thinking why end-point has been added it
> would not be worth it, and for tests only the option requiring end-point
> is enough.
Since tls-unique and tls-server-end-point provide the same level of
security, I don't see any value in allowing prefer-tls-server-end-point,
as you stated above.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
