From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Letting the client choose the protocol to use during a SASL exchange |
Date: | 2017-04-11 11:21:47 |
Message-ID: | 3fb8e0e5-0980-d3db-9438-47ad458245d4@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/11/2017 01:39 PM, Álvaro Hernández Tortosa wrote:
> The fact that you null terminate them (fine with me) doesn't change
> my reasoning. How do you separate multiple channel binding methods? And
> do you realize that you will be repeating the channel binding methods
> without reason? A contrived but legal, possible example:
>
> Field1:
> SCRAM-SHA-256\0
> SCRAM-SHA-512\0
> SCRAM-SHA-999\0
> SCRAM-SHA-256-PLUS tls-unique tls-awesome yet-another-tls\0
> SCRAM-SHA-512-PLUS tls-unique tls-awesome yet-another-tls\0
> SCRAM-SHA-999-PLUS tls-unique tls-awesome yet-another-tls\0
I was actually thinking of:
SCRAM-SHA-256\0
SCRAM-SHA-512\0
SCRAM-SHA-999\0
SCRAM-SHA-256-PLUS\0
SCRAM-SHA-256-PLUS tls-awesome\0
SCRAM-SHA-256-PLUS yet-another-tls\0
SCRAM-SHA-512-PLUS\0
SCRAM-SHA-512-PLUS tls-awesome\0
SCRAM-SHA-512-PLUS yet-another-tls\0
SCRAM-SHA-999-PLUS\0
SCRAM-SHA-999-PLUS tls-awesome\0
SCRAM-SHA-999-PLUS yet-another-tls\0
In practice, I don't foresee us having this many options, so the
verbosity won't be an issue. Parsing this is very straightforward.
>>> vs
>>>
>>> Field 1:
>>> SCRAM-SHA-256,SCRAM-SHA-256-PLUS,SCRAM-SHA-1-PLUS,SCRAM-SHA-512-PLUS
>>> (simple CSV)
>>> Field 2: tls-unique (String)
>>
>> What if tls-unique is only supported with SCRAM-SHA-256-PLUS, while
>> SCRAM-SHA-512-PLUS requires tls-awesome?
>
> It can't happen. The RFC clearly states that they are orthogonal.
> It is left to the implementations support one or the other, but no
> reason to limit applicability of a given binding method to a given SCRAM
> mechanisms (or viceversa).
Well, if tls-unique is found to be insecure, a future SCRAM-SHA-512-PLUS
spec might well define that the default for that mechanism is
tls-unique-new-and-secure rather than tls-unique. Maybe even forbid
using tls-unique altogether. I don't think that's likely, but this is
all about future-proofing, so I'd rather keep it flexible.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Hernández Tortosa | 2017-04-11 11:32:58 | Re: Letting the client choose the protocol to use during a SASL exchange |
Previous Message | Amit Langote | 2017-04-11 11:20:18 | Re: pg_dump emits ALTER TABLE ONLY partitioned_table |