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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
