Received: from malur.postgresql.org ([2a02:16a8:dc51::56])
	by arkaria.postgresql.org with esmtps
 (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.89)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1fSmKV-0001dd-Lv
	for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Jun 2018 16:39:35 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1fSmKU-0006Ju-Hl
	for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Jun 2018 16:39:34 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.89)
	(envelope-from <nico@cryptonector.com>)
	id 1fSmKU-0006Jj-Ae
	for pgsql-hackers@lists.postgresql.org; Tue, 12 Jun 2018 16:39:34 +0000
Received: from homie-sub4.mail.dreamhost.com ([69.163.253.135]
 helo=homiemail-a73.g.dreamhost.com)
	by magus.postgresql.org with esmtps (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <nico@cryptonector.com>)
	id 1fSmKR-00023r-Is
	for pgsql-hackers@postgresql.org; Tue, 12 Jun 2018 16:39:33 +0000
Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 0398D58000938;
	Tue, 12 Jun 2018 09:39:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date
	:from:to:cc:subject:message-id:references:mime-version
	:content-type:in-reply-to; s=cryptonector.com; bh=RzxLyfj4b1tO9Y
	s/XTC/hYmlAAw=; b=uHWEGfJmEyYVQeiMeWAUbPqNuxYzP7oFIfxAk18ithYEpU
	o63s+Qerc43zPGyXqkQFh6IWLEaOsJpRaRUf/YlTWZCQGshe4RL3596WgJF+V3a0
	PSnOM+KZb0IrJx/S9G376fxFOpDWRFFSo/eV11R5sYxV/vLgrbZd/Bwjm4WgM=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com
 [70.123.158.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: nico@cryptonector.com)
	by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id A2E0B58000936;
	Tue, 12 Jun 2018 09:39:26 -0700 (PDT)
Date: Tue, 12 Jun 2018 11:39:24 -0500
From: Nico Williams <nico@cryptonector.com>
To: Robbie Harwood <rharwood@redhat.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH v18] GSSAPI encryption support
Message-ID: <20180612163923.GE23356@localhost>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
 <jlg1se287n3.fsf@redhat.com>
 <jlg602phyn5.fsf@redhat.com>
 <20180611230026.GC23356@localhost>
 <jlgr2lcgdxq.fsf@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jlgr2lcgdxq.fsf@redhat.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

On Tue, Jun 12, 2018 at 12:36:01PM -0400, Robbie Harwood wrote:
> Nico Williams <nico@cryptonector.com> writes:
> > On Mon, Jun 11, 2018 at 04:11:10PM -0400, Robbie Harwood wrote:
> >> Nico was kind enough to provide me with some code review.  This should
> >> those concerns (clarify short-read behavior and fixing error checking on
> >> GSS functions).
> >
> > Besides the bug you fixed and which I told you about off-list (on IRC,
> > specifically), I only have some commentary that does not need any
> > action:
> >
> >  - support for non-Kerberos/default GSS mechanisms
> >
> >    This might require new values for gssmode: prefer-<mechanism-name>
> >    and require-<mechanism-name>.  One could always use SPNEGO if there
> >    are multiple mechanisms to choose from.  And indeed, you could just
> >    use SPNEGO if the user has credentials for multiple mechanism.
> >
> >    (Because GSS has no standard mechanism _names_, this means making
> >    some up.  This is one obnoxious shortcoming of the GSS-API...)
> 
> As long as it's better than passing raw OIDs on the CLI...

Rite?

I think this can be a follow-on patch, though trying SPNEGO if the user
has credentials for multiple mechanisms (and SPNEGO is indicated) seems
simple enough to do now (no interface changes).

> >  - when the SCRAM channel binding work is done, it might be good to add
> >    an option for TLS + GSS w/ channel binding to TLS and no gss wrap
> >    tokens
> 
> I think both of these are neat ideas if they'll be used.  Getting GSSAPI
> encryption in shouldn't preclude either in its present form (should make
> it easier, I hope), but I'm glad to hear of possible future work as
> well!

This one can (must) wait.  It has some security benefits.  You get to
use GSS/Kerberos for authentication, but you get an forward security
you'd get from TLS (if the GSS mechanism doesn't provide it, which
Kerberos today does not).

Nico
--