Re: Proposed patch for key management

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alastair Turner <minion(at)decodable(dot)me>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Subject: Re: Proposed patch for key management
Date: 2021-01-04 18:23:29
Message-ID: 20210104182329.GE7432@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 1, 2021 at 06:26:36PM +0000, Alastair Turner wrote:
> After the long intro, my question - If using a standard format,
> managed by a library, for the internal keystore does not result in a
> smaller or simpler patch, is there enough other value for this to be
> worth considering? For security features, standards and building on
> well exercised code bases do really have value, but is it enough...

I know Stephen Frost looked at PKCS12 but didn't see much value in it
since the features provided by PKCS12 didn't seem to add much for
Postgres, and added complexity. Using GCM for key wrapping, heap/index
files, and WAL seemed simple.

FYI, the current patch has an initdb option --copy-encryption-key, which
copies the key from an old cluster, for use by pg_upgrade. Technically
you could create a directory called pg_cryptokey/live, put wrapped files
0/1 in there, and use that when initializing a new cluster. That would
allow you to generate the data keys using your own random source. I am
not sure how useful that would be, but we could document this ability.

There is all sorts of flexibility being proposed:

* scope of keys
* encryption method
* encryption mode
* internal/external

Some of this is related to wrapping the data keys, and some of it gets
to the encryption of cluster files. I just don't see how anything with
the level of flexibility being asked for could ever be reliable or
simple to administer, and I don't see the security value of that
flexibility. I feel at a certain point, we just need to choose the best
options and move forward.

I thought this had all been debated, but people continue to show up and
ask for it to be debated again. At one level, these discussions are
valuable, but at a certain point you end up re-litigate this that you
get nothing else done. I know some people who have given up working on
this feature for this reason.

I am not asking we stop discussing it, but I do ask we address the
negatives of suggestions, especially when the negatives have already
been clearly stated.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-01-04 19:07:10 Context diffs
Previous Message Michael Banck 2021-01-04 18:11:43 data_checksums enabled by default (was: Move --data-checksums to common options in initdb --help)