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