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

Robert,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Wed, May 31, 2017 at 7:59 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > 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.
>
> OK, great. That's what I mean (mostly - see below).

Glad to hear it.

> > 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 don't think that we need to have a committed patch allowing multiple
> SSL implementations before we accept a patch for channel binding, but
> I think it might be a good idea for someone to hack either libpq or
> the server enough to make it work with some other SSL implementation
> (Windows SSL would probably be the best candidate) and test that what
> we think will work for channel binding actually does work. It
> wouldn't need to be a committable patch, but it should be enough to
> make a successful connection in the laboratory. Now, there might also
> be other ways besides that of testing that interoperability is
> possible, so don't take me as being of the view that someone has to
> necessarily do exactly that thing that I just said. But I do think
> that we probably should do more than say "hey, we've got this
> undocumented SSL API, and this other Windows API, and it looks like
> they do about the same thing, so we're good". There's sometimes a big
> difference between what sounds like it should work on paper and what
> actually does work.

I certainly wouldn't object to someone working on this, but I feel like
it's a good deal more work than perhaps you're realizing (and I tend to
think trying to use the Windows SSL implementation would increase the
level of effort, not minimize it). Perhaps it wouldn't be too bad to
write a one-off piece of code which just connects and then returns the
channel binding information on each side and then one could hand-check
that what's returned matches what it's supposed to based on the RFC, but
if it doesn't, then what? In the specific case we're talking about,
there's two approaches in the RFC and it seems like we should support
both because at least our current JDBC implementation only works with
one, and ideally we can allow for that to be extended to other methods,
but I wouldn't want to implement a method that only works on Windows SSL
because that implementation, for whatever reason, doesn't follow either
of the methods available in the RFC.

Thanks!

Stephen