RE: [Proposal] Table-level Transparent Data Encryption (TDE) andKey Management Service (KMS)

Greetings, 

(Apologies for any naïve thoughts below. Please correct my misunderstandings)

I am trying to understand the background for the ideas proposed and/or already decided, but it is increasingly
difficultto follow.
 

I’ve been watching the TDE list for several months and over that time there have been dozens of different ideas
floated;Each of them have their own good points; Some are conflicting;
 

IMO any TDE implementation will be a trade-off between a number of factors:
* Design – e.g. Simple v Complex solution
* Secureness – e.g. Acceptance that a simpler solution may not handle every possible threat
* Cost/Feasibility – e.g. How hard will TDE be to implement/maintain. 
* User expectations - e.g. What is the “threat model” the end user actually wants to protect against
* User expectations – e.g. Comparison with other products
* Completeness – e.g. Acknowledgement that first implementation may not meet the end-goal.
* Future proof – e.g. ability to evolve in future TDE versions (with minimal re-write of what came before)
* Usability – e.g. Online/offline considerations
* Usability – e.g. Will a more complex solution end up being too difficult to actually use/administer
* etc…

New TDE ideas keep popping up all the time. The discussion sometimes has become mired in technical details; I’m losing
sightof the bigger picture.
 

Would it be possible to share a *tabulation* for all the TDE components; Each component may be a number of design
choices(options); And have brief lists of Pros/Cons for each of those options so that each can be concisely summarised
ontheir respective merits.
 

I think this would be of a great help to understand how we got to where we are now, as well as helping to focus on how
toproceed.
 

For example,

=====
Component: TDKEY
* Option: use derived keys; List of Pros/Cons
* Option: use random keys; List of Pros/Cons
* Option: use keys from some external source and encrypted by MDKEY; List of Pros/Cons
* Option: use same TKEY for all tables/tablespaces; List of Pros/Cons
* Option: … 
* Option: …
* => Decision (i.e. the least-worst compromise/combination of the possible options)
=====

~

Postscript: 

After writing this, I recalled recently reading a mail from Antonin
https://www.postgresql.org/message-id/44057.1565977657%40antoswhich says pretty much the same thing!
 

Also, I recognise that there is an offline shared Googledoc which already includes some of this information, but I
thinkit would be valuable if it could be formatted as Pros/Cons summary table and shared on the Wiki page for everybody
tosee.
 


Kind Regards,
---
Peter Smith
Fujitsu Australia