Re: Add "password_protocol" connection parameter to libpq

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Jeff Davis <pgsql(at)j-davis(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add "password_protocol" connection parameter to libpq
Date: 2019-08-13 23:04:07
Message-ID: 845f3d15-47b0-c274-cd74-035718b62995@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/13/19 6:25 PM, Jeff Davis wrote:
> On Tue, 2019-08-13 at 16:51 -0400, Jonathan S. Katz wrote:
>> Alternatively, we could combine 2 & 3, e.g.:
>>
>> channel_binding = {disable|prefer|require}
>>
>> # comma-separated list of protocols that are ok to the user, remove
>> # ones you don't want. empty means all is ok
>> password_protocol = "plaintext,md5,scram-sha-256,scram-sha-256-
>> plus"
>
> I still feel like lists are over-specifying things. Let me step back
> and offer an MVP of a single new parameter:
>
> channel_binding={prefer|require}
>
> And has a lot of benefits:
> * solves the immediate need to make channel binding useful, which
> is a really nice feature
> * compatible with most of the other proposals we're considering, so
> we can always extend it when we have a better understanding and
> consensus
> * clear purpose for the user
> * doesn't introduce new concepts that might be confusing to the
> user, like SASL or the use of "-plus" to mean "with channel binding"
> * guides users toward the good practice of using SSL and SCRAM
> * simple to implement

+1; I agree with your overall argument. The only thing I debate is if we
want to have an explicit "disable" option. Looking at the negotiation
standard[1] specified for channel binding with SCRAM, I don't think we
need an explicit disable option. I can't think of any good use cases for
"disable" off the top of my head either. The only thing is it would be
consistent with some of our other parameters in terms of having an
explicit "opt-out."

Jonathan

[1] https://tools.ietf.org/html/rfc5802#section-6

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-08-13 23:22:06 Re: Unexpected "shared memory block is still in use"
Previous Message Philip Dubé 2019-08-13 22:43:21 12's AND CHAIN doesn't chain when transaction raised an error