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:

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-PLUS tls-awesome\0
SCRAM-SHA-256-PLUS yet-another-tls\0
SCRAM-SHA-512-PLUS tls-awesome\0
SCRAM-SHA-512-PLUS yet-another-tls\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:


    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 :)


Field 1:
(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


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to