Re: Moving forward with TDE - Mailing list pgsql-hackers

The following review has been posted through the commitfest application:
make installcheck-world:  not tested
Implements feature:       not tested
Spec compliant:           not tested
Documentation:            not tested

I have decided to write a review here in terms of whether we want this feature, and perhaps the way we should look at
encryptionas a project down the road, since I think this is only the beginning.  I am hoping to run some full tests of
thefeature sometime in coming weeks.  Right now this review is limited to the documentation and documented feature.
 

From the documentation, the primary threat model of TDE is to prevent decryption of data from archived wal segments
(anddata files), for example on a backup system.  While there are other methods around this problem to date, I think
thatthis feature is worth pursuing for that reason.  I want to address a couple of reasons for this and then go into
somereservations I have about how some of this is documented.
 

There are current workarounds to ensuring encryption at rest, but these have a number of problems.  Encryption
passphrasesend up lying around the system in various places.  Key rotation is often difficult.  And one mistake can
easilyrender all efforts ineffective.  TDE solves these problems.  The overall design from the internal docs looks
solid. This definitely is something I would recommend for many users.
 

I have a couple small caveats though.  Encryption of data is a large topic and there isn't a one-size-fits-all solution
toindustrial or state requirements.  Having all this key management available in PostgreSQL is a very good thing.  Long
runit is likely to end up being extensible, and therefore both more powerful and offering a wider range of choices for
solutionarchitects.  Implementing encryption is also something that is easy to mess up.  For this reason I think it
wouldbe great if we had a standardized format for discussing encryption options that we could use going forward.  I
don'tthink that should be held against this patch but I think we need to start discussing it now because it will be a
biggerproblem later.
 

A second caveat I have is that key management is a topic where you really need a good overview of internals in order to
implementeffectively.  If you don't know how an SSL handshake works or what is in a certificate, you can easily make
mistakesin setting up SSL.  I can see the same thing happening here.  For example, I don't think it would be safe to
leavethe KEK on an encrypted filesystem that is decrypted at runtime (or at least I wouldn't consider that safe -- your
appetitefor risk may vary).
 

My proposal would be to have build a template for encryption options in the documentation.  This could include topics
likeSSL as well.  In such a template we'd have sections like "Threat model,"  "How it works," "Implementation
Requirements"and so forth.  Again I don't think this needs to be part of the current patch but I think it is something
weneed to start thinking about now.  Maybe after this goes in, I can present a proposed documentation patch.
 

I will also note that I don't consider myself to be very qualified on topics like encryption.  I can reason about key
managementto some extent but some implementation details may be beyond me.  I would hope we could get some extra review
onthis patch set soon.