Date: Mon, 19 Aug 2019 14:51:00 +0900
From: Michael Paquier <michael@paquier.xyz>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
Cc: Stephen Frost <sfrost@snowman.net>, Jeff Davis <pgsql@j-davis.com>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	pgsql-hackers@postgresql.org
Subject: Re: Add "password_protocol" connection parameter to libpq
Message-ID: <20190819055100.GC18166@paquier.xyz>
References: <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>
 <20190814023857.GB14446@paquier.xyz>
 <54269124d50791eacb71f1fead40422185ae8ddc.camel@j-davis.com>
 <20190816012815.GW16436@tamriel.snowman.net>
 <edaeee0d-5367-ad46-6a5a-1357ea595151@postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="mR8QP4gmHujQHb1c"
Content-Disposition: inline
In-Reply-To: <edaeee0d-5367-ad46-6a5a-1357ea595151@postgresql.org>
Precedence: bulk


--mR8QP4gmHujQHb1c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Aug 16, 2019 at 02:11:57PM -0400, Jonathan S. Katz wrote:
> To be pedantic, +1 on the channel_binding param.

Seems like we are moving in this direction then.  I don't object to
the introduction of this parameter.  We would likely want to do
something for downgrade attacks in other cases where channel binding
is not used, still there is verify-ca/full even in this case which
offer similar protections for MITM and eavesdropping.

> I would ask if scram-sha-256-plus makes the list if we have the
> channel_binding param?

No in my opinion.

> If channel_binding = require, it would essentially ignore any non-plus
> options in password_protocol and require scram-sha-256-plus. In a future
> scram-sha-512 world, then having scram-sha-256-plus or
> scram-sha-512-plus options in "password_protocol" then could be
> necessary based on what the user would prefer or require in their
> application.

Not including scram-sha-512-plus or scram-sha-256-plus in the
comma-separated list would be a problem for users willing to give for
example scram-sha-256,scram-sha-512-plus as an authorized list of
protocols but I don't think that it makes much sense as they basically
require an SSL connection for tls-server-end-point per the second
element.
--
Michael

--mR8QP4gmHujQHb1c
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl1aOMQACgkQnvQgOdby
QH1Rnw/8DwdDe2FXbz6hr1ZpfTCoZFSCTQUn7Jtk0B9RgVwEKEnR7foo439YLJpo
BTrQwQ37pZXCPwoL1dG6nzU/dmjs0euJ2Hdl8KgufUeHVqBRmoBKdk/iED1np7ek
wj98jwi9EEePgXDUB1PITh1Z6qVFdMKS4CdwuwxPcFSTQzRyXv1oZ1oPaTIWCrMn
N7xrYb9z7cIUl06dxH9aE8QyxOwYsXVitKAEeSAVGItMSNw1RmQMHTyhMAg/NgyR
7NGOM0EV6iIghZ6PAzzQ/tPzqs21yuBe8FvmY3TL2+7op3lRDNOdXJKu5dL4cky5
Fwc2+3Eskdu+hAY4aNIfMmHvZZM1eY9zLqkLz+2xVzRJsti2+Fv/YX1BABOOaH4Z
jRxskSGCzdQuSPZ8je+yozuNM4PdWJZlO7X44S1V0D6x3C7EmwQngUxKt1qJle0+
F8xb/GDi6IT2IZ52goA/UQFMUN3MkMen1/4lE+XChXx0uZ5UpEUivtlFNG0hH0UM
UNhD46BaFxUqi0UmnH+F51OIgdYX3osFav9JQg1IdNjFPK8R4ZByApi0Exhpzhj5
5DoxYgcFUndncy1+0lxrUopYVO8LESo+0Z+vGE9kK2cS741EdPzl1fBM2BuX8iC5
iJdBL2CvqvsSOkon0Ax1x5J897KzgLtyytDmMQnOxCZni3HaUqI=
=qwzQ
-----END PGP SIGNATURE-----

--mR8QP4gmHujQHb1c--