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
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) |