Re: Moving forward with TDE

On Tue, Mar 28, 2023 at 12:57:42AM +0200, Stephen Frost wrote:
>     I consider the operating system and its processes as much more of a
>     single entity than TLS over a network.
>
> This may be the case sometimes but there’s absolutely no shortage of other
> cases and it’s almost more the rule these days, that there is some kind of
> network between the OS processes and the storage- a SAN, an iSCSI network, NFS,
> are all quite common.

Yes, but consider that the database cluster is having to get its data
from that remote storage --- the remote storage is not an independent
entity that can be corrupted without the databaes server being
compromised. If everything in PGDATA was GCM-verified, it would be
secure, but because some parts are not, I don't think it would be.

>     > As specific examples, consider:
>     >
>     > An attack against the database system where the database server is shut
>     down,
>     > or a backup, and  the encryption key isn’t available on the system.
>     >
>     > The backup system itself, not running as the PG user (an option supported
>     by PG
>     > and at least pgbackrest) being compromised, thus allowing for injection
>     of
>     > changes into a backup or into a restore.
>
>     I then question why we are not adding encryption to pg_basebackup or
>     pgbackrest rather than the database system.
>
> Pgbackrest has encryption and authentication of it … but that doesn’t actually
> address the attack vector that I outlined. If the backup user is compromised
> then they can change the data before it gets to the storage.  If the backup
> user is compromised then they have access to whatever key is used to encrypt
> and authenticate the backup and therefore can trivially manipulate the data.

So the idea is that the backup user can be compromised without the data
being vulnerable --- makes sense, though that use-case seems narrow.

>     What were the _technical_ reasons for those objections?
>
> I believe largely the ones I’m bringing up here and which I outline above… I
> don’t mean to pretend that any of this is of my own independent construction. I
> don’t believe it is and my apologies if it came across that way.

Yes, there is value beyond the check-box, but in most cases those
values are limited considering the complexity of the features, and the
check-box is what most people are asking for, I think.

>     > I’ve grown weary of this argument as the other major piece of work it was
>     > routinely applied to was RLS and yet that has certainly been seen broadly
>     as a
>     > beneficial feature with users clearly leveraging it and in more than some
>     > “checkbox” way.
>
>     RLS has to overcome that objection, and I think it did, as was better
>     for doing that.
>
> Beyond it being called a checkbox - what were the arguments against it?  I

The RLS arguments were that queries could expoose some of the underlying
data, but in summary, that was considered acceptable.

>     > We, as a community, are clearly losing value by lack of this capability,
>     if by
>     > no other measure than simply the numerous users of the commercial
>     > implementations feeling that they simply can’t use PG without this
>     feature, for
>     > whatever their reasoning.
>
>     That is true, but I go back to my concern over useful feature vs. check
>     box.
>
> While it’s easy to label something as checkbox, I don’t feel we have been fair

No, actually, it isn't.  I am not sure why you are saying that.

> to our users in doing so as it has historically prevented features which our
> users are demanding and end up getting from commercial providers until we
> implement them ultimately anyway.  This particular argument simply doesn’t seem
> to actually hold the value that proponents of it claim, for us at least, and we
> have clear counter-examples which we can point to and I hope we learn from
> those.

I don't think you are addressing actual issues above.