On Tue, May 30, 2017 at 11:49 PM, Stephen Frost <sfrost@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