Re: Proposed patch for key managment

On Sat, Dec 19, 2020 at 11:45:15AM +0000, Alastair Turner wrote:
> Sorry, I have waved Desirability through under the headings of ease of
> adoption or not raising barriers to adoption, without detailing what
> barriers I see or how to avoid them. I also realise that "don't scare
> the users" is so open-ended so as to be actively unhelpful and very
> quickly starts to sound like "I want my secret decoder ring to glow
> pink, or blue, or green when anyone asks". Given the complexity of the
> feature and pixels spilled in discussing it, I understand that it gets
> frustrating. That said, I believe there is an important case to be
> made here.

I am pleased you understood my feelings on this. Our last big
discussion on this topic is here:

https://www.postgresql.org/message-id/flat/CA%2Bfd4k7q5o6Nc_AaX6BcYM9yqTbC6_pnH-6nSD%3D54Zp6NBQTCQ%40mail.gmail.com

and it was so unproductive that we started having closed voice calls
every other Friday so we could discuss this without lots of "decoder
ring" ideas that had to be explained. The result is our wiki page:

https://wiki.postgresql.org/wiki/Transparent_Data_Encryption

It has taken me a while to understand why this topic seems to almost
uniquely gravitate toward "decoder ring" discussion.

> In summary, I believe that forcing an approach for key generation and
> wrapping onto users of Cluster File Encryption limits the Desirability
> of the feature.
>
> Cluster File Encryption for Postgres would be Desirable to many users
> I meet if, and only if, the generation and handling of keys fits with
> their corporate policies. Therefore, giving a user the option to pass
> an encryption key to Postgres for CFE is Desirable. I realise that the
> option for feeding the keys in directly is an additional feature, and
> that it has a user experience impact if a passphrase is used. It is,
> however, a feature which opens up near-infinite flexibility. To
> stretch the analogy, it is the clip for attaching coloured or opaque
> coverings to the glowy bit on the secret decoder ring.
>
> The generation of keys and the wrapping of keys are contentious issues
> and are frequently addressed/specified in corporate security policies,
> standards and technical papers (NIST 800-38F is often mentioned in
> product docs). There are, for instance, policies in the wild which
> require that keys for long term use are generated from the output of a
> True Random Number Generator - the practical implication being that
> the key used to encrypt data at rest should be created by an HSM. When
> and why to use symmetric or asymmetric cyphers for key wrapping is
> another item which different organisations have different policies on
> - the hardware and cloud service vendors all offer both options, even
> if they recommend one and make it easier to use.

To enable the direct injection of keys into the server, we would need a
new command for this, since trying to make the passphrase command do
this will lead to unnecessary complexity. The passphrase command should
do one thing, and you can't have it changing its behavior based on
parameters, since the parameters are for the script to process, not to
change behavior of the server.

If we wanted to do this, we would need a new command, and one of the
parameters would be %k or something that would identify the key number
we want to retrieve from the KMS. Stephen pointed out that we could
still validate that key; the key would not be stored wrapped in the
file system, but we could store an HMAC in the file system, and use that
for validation.

On other interesting approach would be to allow the server to call out
for a KMS when it needs to generate the initial data keys that are
wrapped by the passphrase; this is in contrast to calling the KMS
everytime it needs the data keys.

We should create code for the general use-case, which is currently
passphrase-wrapped system-generated data keys, and then get feedback on
what else we need. However, I should point out that the community is
somewhat immune to the "my company needs this" kind of argument without
logic to back it up, though sometimes I think this entire feature is in
that category. The data keys are generated using this random value
code:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/port/pg_strong_random.c;hb=HEAD

so someone would have to explain why generating this remotely in a KMS
is superior, not just based on company policy.

My final point is that we can find ways to do what you are suggesting as
an addition to what we are adding now. What we need is clear
justification of why these additional features are needed. Requiring
the use of a true random number generator is a valid argument, but we
need to figure out, once this is implemented, who really wants that, and
how to implement it cleanly.

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