Re: [PATCH v12] GSSAPI encryption support

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Robbie Harwood <rharwood(at)redhat(dot)com> writes:
>> So there's a connection setting `sslmode` that we'll want something
>> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
>> think we only need three for GSSAPI: "disable", "allow", and "prefer"
>> (which presumably would be the default).
>
> FWIW, there is quite a bit of unhappiness around sslmode=prefer, see
> for example this thread:
> https://www.postgresql.org/message-id/flat/2A5EFBDC-41C6-42A8-8B6D-E69DA60E9962%40eggerapps.at
>
> I do not know if we can come up with a better answer, but I'd caution
> you against thinking that that's a problem-free model to emulate.

Understood. We have the slight simplification for GSSAPI of having
mutual authentication always (i.e., no need to worry about
unauthenticated-but-encrypted connections).

My personal view is that we want to try for as much security as we can
without breaking anything [0]. If a user knows that they want a specific
security, they can set "require"; if they don't want it, they can set
"disable". Setting "require" as the default breaks one class of users;
setting "disable" another. And I don't think we can punt the problem to
the user and make it a mandatory parameter, either.

I'm absolutely open to suggestions for how we could do better here,
especially since we're adding support for something new, but having read
the thread you mention I don't immediately see a superior design.

0: For what it's worth, I also don't agree with the assertion that
having the ability to fallback to plaintext from tampering makes the
attempt at encryption useless; rather, it still foils a passive
adversary, even if it doesn't do anything against an active one.