Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> 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.

I'm hopeful that we're closer to agreement here than we are the
opposite.

It was absolutely not my intent that the ongoing discussion between
Alvaro and Michael be stopped or changed, quite the opposite, in fact.

If your comments regarding the requirement that we have interoperability
testing of this feature before accepting it were intended to mean that
we need to make sure that the JDBC driver is able to work with the
chosen solution (or, perhaps, that we support multuple options, one of
which works with the JDBC changes), and that we review the other TLS
libraries with the goal of making sure that what we agree on in core
should work with those also, then that's great and exactly what I'd like
to see also.

If your comments regarding the requirement that we have interoperability
testing of this feature before accepting it were intended to mean that
we must have a complete alternative TLS solution, while that would
actually play a great deal to a goal I've had for a while to have PG
support multiple TLS implementations (LibNSS being top-of-mind, at least
for me, as I've mentioned a couple times), I can't agree that we should
require that before accepting channel binding as a feature.  To do so
would be akin to requiring that we support multiple TLS implementations
before we agreed to support client-side certificates, in my opinion.

I would be rather surprised if the solution which Michael and Alvaro
come to results in a solution which requires us to break compatibility
down the road, though it's of course a risk we need to consider.  The
ongoing discussion around finding a way to support both methods outlined
in the RFC sounds exactly correct to me and I encourage further
discussion there.

> 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.

I hope it's clear that it's not my intent to throw anyone "under the
bus."  The only reason that "SSL certificates should work with any SSL
implementation" is because those SSL implementations are based on RFCs
which define how they should work and what I was encouraging up-thread
is exactly that we should be looking at RFCs to determine the right path
forward.  There are cases, of course, where the RFCs have alternatives
and the ideal approach is to find a way to work with all of those
alternatives, or at least implement a solution which is flexible, such
that later changes could add support without breaking existing users.

I'm certainly on-board with the general idea of having a way for the
client to require both SCRAM and channel binding and I agree that's a
hole in our current system, but that is really an orthogonal concern.

> 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?

Adding support for channel binding is quite important and valuable, in
its own right.  I concur that we want to provide ways for the client to
require SCRAM and to require channel binding, but I don't see any
particular reason that adding support for channel binding has to be held
up behind that.

As for your question, I have to say that I find it inappropriate to
characterize channel binding as a "buzzword" or to suggest that this
particular feature which Michael and Alvaro are working to add to PG is
only being done to fulfill some marketing requirement or checkbox but
without adding any technical merit in its own right.  Channel binding
isn't new, it's supported by quite a few different technologies, and we
would absolutely be better off including support for it, from an
entirely technical perspective.  If I were one of the individuals
working on this feature, I'd be rather put-off and upset at the
suggestion that the good work they're doing is viewed by the PostgreSQL
community and one of our major committers as only being done to check a
box or to be "buzzword compliant" and ultimately without technical
merit.

Thankfully, I know both Michael and Alvaro and had excellent discussions
with them at PGCon last week, and I don't doubt that they will continue
their efforts regardless, but I worry about the signal it sends to
individuals who are not yet contributors or who have not gone through
the process of trying to contribute to PostgreSQL.  We make it more than
difficult enough to get code into core, let's try to avoid discouraging
contributors by casting doubt on the technical merits of their efforts
when they're very clearly adding a useful feature, even if it isn't
perfect until we also add X, Y or Z.  Instead, let's encourage their
efforts to complete the work they've started and then work with them to
add those other components necessary to have a complete solution.

Thanks!

Stephen