Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Jun 1, 2017 at 11:50 AM, Stephen Frost <sfr...@snowman.net> wrote: > > 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). > > I agree that it's a fair amount of work, but if nobody does it, then I > think it's pretty speculative to suppose that the feature actually > works correctly.
We've considered "works with OpenSSL" (and, to some extent, JDBC, but I'm pretty sure that came later and just happened to be able to work...) to be sufficient to include things like client-side certificate based authentication, so this is raising the bar quite a bit for a feature that, while important and valuable, frankly isn't as important as client-side cert auth. > > 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? > > Then something's broken and we need to fix it before we start > committing patches. ... Or that implementation doesn't follow the RFC, which is what I was getting at. > > 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. > > I am very skeptical that if two people on two different SSL > interpretations both do something that appears to comply with the RFC, > we can just assume those two people will get the same answer. In an > ideal world, that would definitely work, but in the real world, I > think it needs to be tested or you don't really know. I agree that if > a given SSL implementation is such that it can't support either of the > possible channel binding methods, then that's not our problem; people > using that SSL implementation just can't get channel binding, and if > they don't like that they can switch SSL implementations. But I also > think that if two SSL implementations both claim to support what's > needed to make channel binding work and we don't do any testing that > they actually interoperate, then I don't think we can really know that > we've got it right. I'm all for doing testing, as I've tried to point out a few times, and I would like to see an implementation which is able to be extended in the future to other channel binding methods, as we clearly need to support at least the two listed in the RFC based on this discussion and there might be a still better way down the road anyway. > Another way of validating Michael's problem which I would find > satisfactory is to go look at some other OpenSSL-based implementations > of channel binding. If in each case they are using the same functions > that Michael used in the same way, then that's good evidence that his > implementation is doing the right thing, especially if any of those > implementations also support other SSL implementations and have > verified that the OpenSSL mechanism does in fact interoperate. I don't have any issue with asking that Michael, or someone, to go look at other OpenSSL-using implementations which support channel binding. > I don't really know why we're arguing about this. It seems blindingly > obvious to me that we can't just take it on faith that the functions > Michael identified for this purpose are the right ones and will work > perfectly in complete compliance with the RFC. We are in general very > reluctant to make such assumptions and if we were going to start, > changes that affect wire protocol compatibility wouldn't be my first > choice. Is it really all that revolutionary or controversial to > suggest that this patch has not yet had enough validation to really > know that it does what we want? To me, it seems like verifying that a > patch which supposedly implements a standard interoperates with > something other than itself is so obvious that it should barely need > to be mentioned, let alone become a bone of contention. As I said in an earlier reply, I'm hopefuly that we're closer to agreement here than we are disagreement, but there seems to be some confusion regarding my position on this specific patch. I'm not advocating for this patch to be committed as-is or even anytime soon, and I'm unsure of where I gave that impression. I'm encouraged by the ongoing discussion between Michael and Alvaro and hope to see a new patch down the road which incorporates the results of their discussion and works with both OpenSSL and the JDBC implementation, at least. What I find somewhat objectionable is the notion that if we don't have 5 different TLS/SSL implementations supported in PG and that we've tested that channel binding works correctly among all combinations of all of them, then we can't accept a patch implementing it. I'm exaggerating for effect here, of course, and you've agreed that a full, committable, implementation isn't necessary, and I agreed with that, but we still seem to have a different level of expectation regarding what needs doing here. I don't know that we'll ever be able to nail down the exact location of the line in the sand that needs to be crossed here, or agree to it, so I'd suggest that we let them continue their efforts to work together and provide a patch which they feel is ready to be commented on by committers. Perhaps we'll find that, regardless of where the line was drawn exactly, they've crossed it. Thanks! Stephen
signature.asc
Description: Digital signature
