Message-ID: <daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.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>, Stephen Frost
	 <sfrost@snowman.net>, Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@postgresql.org
Date: Fri, 09 Aug 2019 14:56:28 -0700
In-Reply-To: <071e45a6-97f7-1614-371c-98ecb03aed65@postgresql.org>
References: <227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel@j-davis.com>
	 <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>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Fri, 2019-08-09 at 16:27 -0400, Jonathan S. Katz wrote:
> Seems to be a lot to configure. I'm more of a fan of the previous
> method; it'd work nicely with how we've presently defined things and
> should be easy to put into a DSN/URI/env variable.

Proposals on the table:

1. Hierarchical semantics, where you specify the least-secure
acceptable method:

  password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}

2. Comma-list approach, where you specify exactly which protocols are
acceptable, or "any" to mean that we don't care.

3. three-setting approach:

  channel_binding = {disable|prefer|require}
  password_plaintext = {disable|enable}
  password_md5 = {disable|enable}

It looks like Jonathan prefers #1.

#1 seems direct and clearly applies today, and corresponds to auth
methods on the server side.

I'm not a fan of #2, it seems likely to result in a bunch of clients
with overly-specific lists of things with long names that can never
really go away.

#3 is a little more abstract, but also seems more future-proof, and may
tie in to what Stephen is talking about with respect to controlling
auth methods from the client, or moving more protocols within SASL.

Regards,
	Jeff Davis