On Tue, Jun 12, 2018 at 6:49 AM, Michael Paquier <mich...@paquier.xyz> wrote:
> On Mon, Jun 11, 2018 at 04:54:45PM +0200, Magnus Hagander wrote: > > I'm wondering if that means we should then also not do it specifically > for > > scram in this version. Otherwise we're likely to end up with a parameter > > that only has a "lifetime" of one version, and that seems like a bad > idea. > > If nothing else we should clearly think out what the path is to make sure > > that doesn't happen. (e.g. we don't want a > > scram_channel_binding_mode=require in this version, if the next one is > > going to replace it with something like heikkis suggested > > allowed_authentication_methods=SCRAM-SHA-256-PLUS or whatever we end up > > coming up with there). > > Conceptually, it depends on if we consider SCRAM and > SCRAM+channel_binding as two separate authentication protocols. However > it seems to me that as both are the same thing as they use the same > protocol so it would be confusing for the user to be able to define both > SCRAM-SHA-256 and SCRAM-SHA-256-PLUS within the same list, so I would > tend to think that we should have in this future > "allowed_authentication_methods" only scram-sha-256 listed as an option, > which counts for both SCRAM with and without channel binding. > One could argue they are equally the same protocol if we have SCRAM-SHA-512 or whatever in the future. So how would those be handled? Thinking harder about this thread, it could be as well possible in the > future that we add support for channel binding for some other SASL > mechanism, in which case I would tend to rename > scram_channel_binding_type and scram_channel_binding_mode to simply > channel_binding_type and channel_binding_mode, without any concepts of > SCRAM attached to it. So in short, I'd like to keep both enforcement > mechanisms as separate concepts. One future compatibility issue is how > to deal with for example cases like allowed_authentication_methods="md5" > and channel_binding_mode=require where an allowed authentication does > not have channel binding? And it seems to me that this should result in > an error. > Yeah, not embedding scram in the name seems smarter. But you might still need to define which one, so channel_binding_mode=require wouldn't be enough in that case -- you'd need to have channel_binding_mode=require-scram-sha-256-plus, wouldn't you? And yes, in your suggested example, it should absolutely fail early, as there is no way to actually connect with that setting. Arguably we should also fail on e.g. sslmode=require over a unix socket, though, which we don't. But that is probably not somethign to copy :) I still think that the fact that we are still discussing what is basically the *basic concepts* of how this would be set up after we have released beta1 is a clear sign that this should not go into 11. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
