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

Greetings,

* Chris Travers (chris.travers@gmail.com) wrote:
> 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.
 

Agreed, though the latest efforts include an option for *authenticated*
encryption as well as unauthenticated.  That makes it much more
difficult to make undetected changes to the data that's protected by
the authenticated encryption being used.

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

There's clearly user demand for it as there's a number of organizations
who have forks which are providing it in one shape or another.  This
kind of splintering of the community is actually an actively bad thing
for the project and is part of what killed Unix, by at least some pretty
reputable accounts, in my view.

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

Do you have a suggestion as to the format to use?

> A second caveat I have is that key management is a topic where you really need a good overview of internals in order
toimplement effectively.  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).
 

Agreed that we should document this and make clear that the KEK is
necessary for server start but absolutely should be kept as safe as
possible and certainly not stored on disk somewhere nearby the encrypted
cluster.

> 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'm not entirely sure that it makes sense to lump this and TLS in the
same place as they end up being rather independent at the end of the
day.  If you have ideas for how to improve the documentation, I'd
certainly encourage you to go ahead and work on that and submit it as a
patch rather than waiting for this to actually land in core.  Having
good and solid documentation is something that will help this get in,
after all, and to the extent that it's covering existing topics like
TLS, those could likely be included independently and that would be of
benefit to everyone.

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

Certainly agree with you there though there's an overall trajectory of
patches involved in all of this that's a bit deep.  The plan is to
discuss that at PGCon (On the Road to TDE) and at the PGCon
Unconference after.  I certainly hope those interested will be there.
I'm also happy to have a call with anyone interested in this effort
independent of that, of course.

Thanks!

Stephen