Re: [HACKERS] WIP: Data at rest encryption

On Thu, Jun 15, 2017 at 7:51 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> I thought we called it "incremental development".  From the opposite
> point of view, would you say we should ban use of passphrase-protected
> SSL key files because the current user interface for them is bad?

I think that we've got a number of features which exist in the tree
today only because either (a) our standards were lower at the time
that those features were committed than they are today or (b) we
didn't realize how much trouble those features were going to create.
Just because we don't want to hose the people already using those
features does not mean that we want more features engineered to that
same quality level.  Obviously, there's room for debate in any
particular case about how reasonable it is to expect someone who wants
to implement A to also improve B, and, well, maybe handling thing as
we do SSL certificates is good enough for this feature, too.  I find
myself a bit skeptical about that, though.  It preclude as lot of
things we might want to do.  You're not going to be able to interface
with some external key management server that way, nor do encryption
of only part of the database, nor have multiple keys for different
parts of the database using that kind of setup.

One could argue that can all be added later, but I think there's a
question about how much that's going to affect the code structure.
Surely we don't want to install encryption v1 and then find that, by
not considering key management, we've made it really hard to get to
v2, and that it basically can't be done without ripping the whole
implementation out and replacing it.  Maybe the database needs, at
some rather low level, a concept of whether the encryption key (or an
encryption key) is available yet, and maybe you get out of considering
that by deciding you're just going to prompt very early in startup,
but now when someone comes along and wants to improve things later,
and they've got to try to go find all of the code that depends on the
assumption that the key is always available and fix it.  That could be
pretty annoying to validate.  I think it's better to give at least
some consideration to these key management questions from the
beginning, lest we back ourselves into a corner.  Whether or not the
SSL-passphrase style implementation is above or below the level we'd
consider a minimally viable feature, it's surely not where we want to
end up, and we shouldn't do anything that makes it likely that we'll
get stuck at precisely that point.

Also, practically, I think that type of solution is going to be
extremely difficult to use for most people.  It means that the
database can't be started by the system startup scripts; you'll have
to log into the PG OS user account and launch the database from there.
IIUC, that means it won't be able to be controlled by things like
systemd, that just know about start and stop, but not about ask for a
password in the middle.  Maybe I'm wrong about that, though.  And
certainly, there will be some users for whom starting the database
manually and prompting for a password will be good enough, if not
ideal.  But for people who want to fetch the encryption key from a key
management server, which I bet is a lot of people, that's not really
going to be good enough.  I'm not really sure that rushing a first
patch that "works" for sufficiently small values of "works" is
actually going

> I have no use for data-at-rest encryption myself, but I wouldn't stop
> development just because the initial design proposal doesn't include
> top-notch key management.


-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company