From: Robbie Harwood <rharwood@redhat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael.paquier@gmail.com>,
        PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
        Stephen Frost <sfrost@snowman.net>
Subject: Re: [PATCH v12] GSSAPI encryption support
In-Reply-To: <18337.1469546948@sss.pgh.pa.us>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
 <jlgy48ssyvl.fsf@thriss.redhat.com>
 <20160406112105.GG10850@tamriel.snowman.net>
 <jlg1t6isftk.fsf@thriss.redhat.com> <1530.1459977031@sss.pgh.pa.us>
 <jlgy48qqt86.fsf@thriss.redhat.com> <5486.1459984857@sss.pgh.pa.us>
 <CAB7nPqRPK1f4oAStwsy_Ty_Cjjo8U50HF0bRZi86my7va4nVdg@mail.gmail.com>
 <jlgk2hq3uvr.fsf@thriss.redhat.com> <jlg7fc91lko.fsf@thriss.redhat.com>
 <CAB7nPqSmq1tuVGoVQXVb86y9SoaM-wcMDxHD1of9dGc54QYNSQ@mail.gmail.com>
 <jlg7fc8fmq7.fsf@thriss.redhat.com> <18337.1469546948@sss.pgh.pa.us>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Tue, 26 Jul 2016 12:24:39 -0400
Message-ID: <jlgy44oe5a0.fsf@thriss.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--=-=-=
Content-Type: text/plain

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Robbie Harwood <rharwood@redhat.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.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJXl47HAAoJECUy+RdqlaRCRrQP/i2Qy4oe6fLyETfDXysnwGrg
JuLELp0bucAL+TvTYeQBJlw9MlKIvcnXmVKRMesWVPMUsb8WiZt/u5OflyCsSuAI
hgeoslnpoplT7SExpstOWfFHIH9aJB9pAbhNhW/EVm6WnRDHN553Z+qPWkbnkxUl
CR4FPjAB3W9slEpc/aLl8MjtGcfUCq+WT+MYIK+U1HAgFGwpdYOf0O/6CZa92HB4
9SIG0XWZnL803nxPfbwIr+qC5v57jpqG7SDZgTKU2+xL8B5DyNftSCkC7h3cDEIc
4WODuB45kor7f/EGe7WvdalNLsHhGVZTSgq48K+BvSRtEGtjFNsrngOunaM74l1H
pHlitTv4xQXZmRR+UxHk0UaMUHqHQ48uY8oEBn0gGoa4jdGGN9FSHziS3PHYfdRA
iLIHhB+nXOrZpmk1VdfxPrE0oK30rpr4rYdeDZFf8N90kJsbFtKOPspXcNm1rnZ3
nBreoB7NJD1wz6NBecTnIta5lUwkd7LbqvUPETpoET64UeGWa9eoekskfWIl+7Gg
nJdWtR9LE2hrv+kij7NUF3aMwJT9tJsdeEFSRPInzMqHJNLIxpOGqbylUVRsn8aj
d5vy2czWATvb5qDJvKWDiJdZPPz4Z5DFRJVs5K6o7kxGrp1I+h8oW+R28tqSC8me
UmsGuOK09affEXjNb1P0
=0T1Q
-----END PGP SIGNATURE-----
--=-=-=--