From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: SCRAM with channel binding downgrade attack |
Date: | 2018-05-26 14:42:38 |
Message-ID: | 20180526144237.GA1547@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-www |
On Sat, May 26, 2018 at 09:08:50AM -0400, Bruce Momjian wrote:
> On Sat, May 26, 2018 at 08:32:20AM +0900, Michael Paquier wrote:
>>
>> OK, I can live with that as well. So we'll go in the direction of two
>> parameters then:
>> - scram_channel_binding, which can use "prefer" (default), "require" or
>> "disable".
>> - scram_channel_binding_name, developer option to choose the type of
>> channel binding, with "tls-unique" (default) and "tls-server-end-point".
>> We could also remove the prefix "scram_". Ideas of names are welcome.
>
> scram_channel_binding_method?
Or scram_channel_binding_type. The first sentence of RFC 5929 uses this
term.
> Do we really know someone is going to want to actually specify the
> channel binding type? If it is only testing, maybe we don't need to
> document this parameter.
Keeping everything documented is useful as well for new developers, as
they need to guess less from the code. So I would prefer seeing both
connection parameters documented, and mentioning directly in the docs if
a parameter is for developers or not.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-05-26 14:47:16 | Re: jsonb iterator not fully initialized |
Previous Message | Tom Lane | 2018-05-26 14:08:57 | Re: Avoiding Tablespace path collision for primary and standby |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-05-28 01:23:28 | Re: SCRAM with channel binding downgrade attack |
Previous Message | Bruce Momjian | 2018-05-26 13:08:50 | Re: SCRAM with channel binding downgrade attack |