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