On Tue, Jan 5, 2021 at 10:18 AM Bruce Momjian <br...@momjian.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.
