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 <br...@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 +
