Re: Internal key management system

Hello Masahiko-san,

>> I am sharing here a document patch based on top of kms_v10 that was
>> shared awhile back. This document patch aims to cover more design
>> details of the current KMS design and to help people understand KMS
>> better. Please let me know if you have any more comments.

A few questions and comments, mostly about the design. If I'm off topic,
or these concerns have been clearly addressed in the thread, please accept
my apology.

A lot of what I write is based on guessing from a look at the doc & code
provided in the patch. The patch should provide some explanatory README
about the overall design.

It is a lot of code, which for me should not be there, inside the backend.
Could this whole thing be an extension? I cannot see why not. If it could,
then ISTM that it should. If not, what set of features is needed to allow
that as an extension? How could pg be improved so that it could be an
extension?

Also, I'm not at fully at ease with some of the underlying principles
behind this proposal. Are we re-inventing/re-implementing kerberos or
whatever? Are we re-implementing a brand new KMS inside pg? Why having
our own?

I think that key management should *not* belong to pg itself, but to some
external facility/process with which pg would interact, so that no master
key would ever be inside pg process, and possibly not on the same host, if
it was me doing it.

If some extension could provide it inside the process and stores thing
inside some pg_cryptokeys directory, then fine if it fits the threat model
being addressed, but the paranoïd user wanting that should have other
options which could be summarized as "outside".

Another benefit of "outside" is that if there is a security issue attached
to the kms, then it would not be a pg security issue, and it would not
affect normal pg users which do not use the feature.

Also, implementing a crash-safe key rotation algorithm does not look like
inside pg backend, that is not its job. Likewise, the AEAD AES-CBC
HMAC-SHA512 does definitely not belong to postgres core backend
implementation. Why should I use the OpenSSL library and not some other
facility?

Basically, I'm -1 on having such a feature right inside pg, and +1 on
allowing pg to have it outside and interact with it appropriately,
preferably through an extension which could be in core.

So my take is that pg should allow an extension to:

- provide a *generic* way to interact with an *external* kms
eg by running a command (possibly setuid something) and interacting
with its stdin/stderr what the command does should be of no concern
to pg and use some trivial text protocol, and the existing code
can be wrapped as an example working implementation.

- store some local keys somewhere and provide functions to use these
keys to encrypt/decrypt stuff, obviously, as generic as possible.

ISTM that what crypto algorithms are actually used should not be
hardcoded, but I'm not sure how to achieve that. Maybe simply by
redefining the relevant function, maybe at the SQL level.

There is an open question on how the "command" validates that it is indeed
the right pg which is interacting with it. This means some authentication,
probably some passphrase to provide somehow, probably close to what is
being implemented, so from an interface point of view, it could look quite
the same, but the key point is that the whole thing would be out of
postgres process, only encryption keys being used would be in postgres,
and probably only in the process which actually needs it.

Random comments about details I saw in passing:

* key_management_enabled

key_management (on|off) ?

* initdb -D dbname --cluster-passphrase-command="cat /path/to/passphrase-file"

Putting example in the documentation looks like a recommendation. It would
put a caveat that doing the above is probably a bad idea.

--
Fabien.