Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange - Mailing list pgsql-hackers

On 11/04/17 13:21, Heikki Linnakangas wrote:
> 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.
    That's maybe slightly better, since -I agree- verbosity is not an 
issue. But parsing (parsers, and validators) are still more complex (you 
need to check that if suffix is -PLUS you need to split by space and 
find another field with another format based on another lookup table of 
IANA registry names and so forth). Vs: this field is for SCRAM names, 
this field is for channel binding names. Done.
    Let me exemplify. In Java-ish syntax, your type would be something 
like:

List<Pair<ScramMechanism,ChannelBindingType>> from where you need to 
extract individually ScramMechanisms and unique(ChannelBindingType)
    My proposal would have two lists:

List<ScramMechanism>
List<ChannelBindingType>
    which is exactly what you need.
    So I still see your proposal more awkward and less clear, mixing 
things that are separate. But again, your choice  :)

>
>>>> 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.
    If it would be insecure, I'd immediately stop it from being 
advertised, and problem solved. Nothing would change (under my proposal).

-- 

Álvaro Hernández Tortosa


-----------
<8K>data