Re: Proposed patch for key managment

Hi Bruce

On Sat, 19 Dec 2020 at 02:38, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> I am not going be as kind. Our workflow is:
>
> Desirability -> Design -> Implement -> Test -> Review -> Commit
> https://wiki.postgresql.org/wiki/Todo#Development_Process
>
> I have already asked about the first item, and received a reply talking
> about the design --- that is not helpful. I only have so much patience
> for the "I want my secret decoder ring to glow in the dark" type of
> feature additions to this already complex feature. Unless we stay on
> Desirability, I will not be replying. If you can't answer the
> Desirability question, well, talking about items farther right on the
> list is not very helpful.
>
> Now, I will say that your question about how a KMS will use this got me
> thinking about how to test this, and that got me to implement the AWS
> Secret Manager script, so that we definitely helpful. My point is that
> I don't think it is helpful to get into long discussions unless the
> Desirability is clearly answered. This is not just related to this
> thread --- this kind of jump-over-Desirability has happened a lot in
> relation to this feature, so I thought it would be good to clearly state
> it now.
>

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.

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.

Thanks

Alastair