On Sat, 2019-08-10 at 10:24 +0800, Craig Ringer wrote:
> Before we go too far along with this, lets look at how other
> established protocols do things and the flaws that've been discovered
> in their approaches. If this isn't done with extreme care then
> there's a large risk of negating the benefits offered by adopting
> recent things like SCRAM.
Agreed. I'm happy to hear any proposals better informed by history.
> Frankly I kind of wish we could just use SASL, but there are many
> (many) reasons no to.
I'm curious what the reasons are not to use SASL; do you have a
reference?
> Off the top of my head I can think of these risks:
>
> * Protocols that allow naïve pre-auth client/server auth negotiation
> (e.g. by finding the overlap in exchanged supported auth-mode lists)
> are subject to MiTM downgrade attacks where the attacker filters out
> protocols it cannot intercept and break from the proposed
> alternatives.
We already have the downgrade problem. That's what I'm trying to solve.
> * Protocols that specify a hierarchy tend to be inflexible and result
> in hard to predict auth mode selections as the options grow. If my
> app wants GSSAPI or SuperStrongAuth but doesn't accept SSPI, and the
> hierarchy is GSSAPI > SSPI > SuperStrongAuth, it has to fall back to
> a disconnect and retry model like now.
What do you mean "disconnect and retry model"?
I agree that hierarchies are unweildly as the options grow. Then again,
as options grow, we need new versions of the client to support them,
and those new versions might offer more flexible ways to choose between
them.
Of course, we should try to think ahead to avoid needing to constantly
change client connection syntax, but I'm just pointing out that it's
not a one-way door.
> * Protocols that announce supported auth methods before any kind of
> trust is established make life easier for vulnerability scanners and
> worms
This discussion is about the client so I don't see how vulnerability
scanners are relevant.
Regards,
Jeff Davis
