Re: Proposed patch for key management

On Tue, Jan 5, 2021 at 10:18 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Fri, Jan 1, 2021 at 06:26:36PM +0000, Alastair Turner wrote:
>
> 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.
>
> +1.

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.
>
> Well, in fact, because the discussion about TDE/KMS has several very long
threads, maybe not everyone can read them completely first, and inevitably,
there will be topics that have already been discussed.

At least for the initial version, I think we should pay more attention to
whether the currently provided functions are acceptable, instead of always
staring at what it lacks, and how it should be more flexible.

For basic KMS functions, we need to ensure its stability and safety. Use a
more flexible API to support different encryption algorithms. Yes, it does
look more powerful, but it does not see much value for stability and
security. Regardless of whether we want to do this or not, but I think this
can at least not be discussed in the first version. We will not discuss
whether it is safer to use more keys, or even introduce HSM management. We
only evaluate whether this design can resist attacks under our Threat_models
<https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#Threat_models>
as the initial version.

Of course, the submission of a feature needs to accept the opinions of many
people, but for a large and complex feature, I think that dividing the
stage to limit the scope of the discussion will help us avoid getting into
endless disputes.

--
There is no royal road to learning.
HighGo Software Co.