From: Jonathan S. Katz <jkatz@postgresql.org>
To: Jeff Davis <pgsql@j-davis.com>
To: Michael Paquier <michael@paquier.xyz>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Add "password_protocol" connection parameter to libpq
Date: Tue, 13 Aug 2019 16:51:57 -0400
Message-ID: <1e34ce7a-9d4c-dd99-3781-e0a3203f5aef@postgresql.org> (raw)
In-Reply-To: <67726b008fa31d00d9a38257b3d1673b8afff2dd.camel@j-davis.com>
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>
On 8/13/19 12:25 PM, Jeff Davis wrote:
> On Tue, 2019-08-13 at 11:56 +0900, Michael Paquier wrote:
>> I tend to prefer #2 as well and that's the kind of approach we were
>> tending to agree on when we discussed this issue during the v11 beta
>> for the downgrade issues with libpq. And as you say extend it so as
>> we can apply filtering of more AUTH_REQ requests, inclusing GSS and
>> krb5.
>
> Can you please offer a concrete proposal? I know the proposals I've put
> out aren't perfect (otherwise there wouldn't be three of them), so if
> you have something better, please share.
I think all of them get at the same thing, i.e. specifying which
password protocol you want to use, and a lot of it is a matter of how
much onus we want to put on the user.
Back to the thee proposals[1], I've warmed up to #3 a bit. I do think it
puts more onus on the client to set the correct knobs to get the desired
outcome, but what I like is the specific `channel_binding=require`
attribute.
However, I don't think it's completely future proof to adding a new hash
digest. If we wanted to prevent someone from using scram-sha-256 in a
scram-sha-512 world, we'd likely need an option for that.
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"
If the client selects "channel_binding=require" but does not include a
protocol that supports it, we should error. Likewise, if the client does
something like "channel_binding=require" and
"password_protocol=scram-sha-256,scram-sha-256-plus" but the server
refuses to do channel binding, we should error.
I think this gives us both future-proofing against newer password digest
methods + the fix for the downgrade issue.
I would not be opposed to extending "password_protocol" to read
"auth_protocol" or the like and work for everything covered in AUTH_REQ,
but I would need to think about it some more.
Thanks,
Jonathan
[1]
https://www.postgresql.org/message-id/daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel%40j-davis.comAttachments:
[application/pgp-signature] signature.asc (832B, ../1e34ce7a-9d4c-dd99-3781-e0a3203f5aef@postgresql.org/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jkatz@postgresql.org, pgsql@j-davis.com, michael@paquier.xyz, peter.eisentraut@2ndquadrant.com, sfrost@snowman.net
Subject: Re: Add "password_protocol" connection parameter to libpq
In-Reply-To: <1e34ce7a-9d4c-dd99-3781-e0a3203f5aef@postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox