On Tue, May 30, 2017 at 11:49 PM, Stephen Frost <sfr...@snowman.net> wrote: > ... and I don't believe that we should be asking the > implementors of channel binding to also implement support for multiple > TLS libraries in PostgreSQL in order to test that their RFC-following > (at least, as far as they can tell) implementation actually works.
You're of course free to believe what you wish, but that sounds short-sighted to me. If we implement channel binding and it turns out not to be interoperable with other SSL implementations, then what? We can't change it later without breaking compatibility with our own prior implementation. Note that Álvaro Hernández Tortosa said about two hours before you sent this email that it doesn't seem possible to implement something comparable in Java's standard SSL stack. If that's the case, adopting this implementation is dooming everyone who connects to the database server using JDBC to be unable to use channel binding. And that's a large percentage of our user base. And then what happens when we do add support for Windows SSL or macOS SSL? It sounds like you're equally willing to throw people using those implementations under the bus. So we'll end up with channel binding that works only when everybody's running the same operating system and nobody's using Java. Uggh. At that point you might as well just go back to using SSL certificates to solve this problem. If you use SSL certificates, then (1) it should work with any SSL implementation and (2) the client can force SSL certificate verification, whereas currently the client cannot force even the use of SCRAM, let alone channel binding. So what is being proposed here does not (yet, anyway) provide any actual security and seems to have poor prospects for interoperability, whereas we have an existing feature (SSL certificates) that has neither of those problems. Are you sure you're not putting buzzword-compliance ahead of real progress? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
