Re: Letting the client choose the protocol to use during a SASL exchange

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