Message-ID: <c57b140decb72a8b5a845a33a23dbc0bcee6c111.camel@j-davis.com>
Subject: Re: Add "password_protocol" connection parameter to libpq
From: Jeff Davis <pgsql@j-davis.com>
To: "Jonathan S. Katz" <jkatz@postgresql.org>, Michael Paquier
	 <michael@paquier.xyz>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>, pgsql-hackers@postgresql.org
Date: Tue, 13 Aug 2019 15:25:06 -0700
In-Reply-To: <1e34ce7a-9d4c-dd99-3781-e0a3203f5aef@postgresql.org>
References: <20190809030021.GG3194@paquier.xyz>
	 <3bbf5968ea705700a2605d6db74d8510bea7940b.camel@j-davis.com>
	 <20190809100922.GI3194@paquier.xyz>
	 <20190809132850.GL16436@tamriel.snowman.net>
	 <609482826475e0063c7d71b2449ae31c0d61b232.camel@j-davis.com>
	 <071e45a6-97f7-1614-371c-98ecb03aed65@postgresql.org>
	 <daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel@j-davis.com>
	 <7a7a2f07-d013-eb80-85ba-9edaaf845038@2ndquadrant.com>
	 <95b40ddcb3897772f075e6891521ee3f06f443d1.camel@j-davis.com>
	 <93653d2b-7cf7-6992-7d3e-600ffd461354@2ndquadrant.com>
	 <20190813025634.GF2551@paquier.xyz>
	 <67726b008fa31d00d9a38257b3d1673b8afff2dd.camel@j-davis.com>
	 <1e34ce7a-9d4c-dd99-3781-e0a3203f5aef@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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

The other use cases are less clear to me, and seem less urgent.

Regards,
	Jeff Davis