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

From: "Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Antonin Houska <ah(at)cybertec(dot)at>, "Sehrope Sarkuni" <sehrope(at)jackdb(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Date: 2019-08-27 02:25:16
Message-ID: 201DD0641B056142AC8C6645EC1B5F62014B893F27@SYD1217
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 difficult to 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 sight of 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 on their 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 to proceed.

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%40antos which 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 think it would be valuable if it could be formatted as Pros/Cons summary table and shared on the Wiki page for everybody to see.

Kind Regards,
---
Peter Smith
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex 2019-08-27 02:59:44 Re: understand the pg locks in in an simple case
Previous Message Alexander Korotkov 2019-08-27 02:19:00 Re: Support for jsonpath .datetime() method