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

On Tue, Mar 28, 2023 at 12:01:56AM +0200, Stephen Frost wrote:
> Greetings,
>
> On Mon, Mar 27, 2023 at 12:38 Bruce Momjian <bruce@momjian.us> wrote:
>
>     On Wed, Mar  8, 2023 at 04:25:04PM -0500, Stephen Frost wrote:
>     > 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.
>
>     I thought some more about this.  GCM-style authentication of encrypted
>     data has value because it assumes the two end points are secure but that
>     a malicious actor could modify data during transfer.  In the Postgres
>     case, it seems the two end points and the transfer are all in the same
>     place.  Therefore, it is unclear to me the value of using GCM-style
>     authentication because if the GCM-level can be modified, so can the end
>     points, and the encryption key exposed.
>
>
> What are the two end points you are referring to and why don’t you feel there
> is an opportunity between them for a malicious actor to attack the system?

Uh, TLS can use GCM and in this case you assume the sender and receiver
are secure, no?

> There are simpler cases to consider than an online attack on a single
> independent system where an attacker having access to modify the data in
> transit between PG and the storage would imply the attacker also having access
> to read keys out of PG’s memory. 

I consider the operating system and its processes as much more of a
single entity than TLS over a network.

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

> The beginning of this discussion also very clearly had individuals voicing
> strong opinions that unauthenticated encryption methods were not acceptable as
> an end-state for PG due to the clear issue of there then being no protection
> against modification of data.  The approach we are working towards provides

What were the _technical_ reasons for those objections?

> both the unauthenticated option, which clearly has value to a large number of
> our collective user base considering the number of commercial implementations
> which have now arisen, and the authenticated solution which goes further and
> provides the level clearly expected of the PG community. This gets us a win-win
> situation.
>
>     > 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.
>
>     Yes, the number of commercial implementations of this is a concern.  Of
>     course, it is also possible that those commercial implementations are
>     meeting checkbox requirements rather than technical ones, and the
>     community has been hostile to check box-only features.
>
>
> 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.

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