From: Bruce Momjian <bruce@momjian.us>
To: Alastair Turner <minion@decodable.me>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Subject: Re: Proposed patch for key managment
Date: Wed, 16 Dec 2020 13:42:57 -0500
Message-ID: <20201216184257.GA4527@momjian.us> (raw)
In-Reply-To: <CAC0Gmyy7QCvh4ey-e_XXYCHDEmaKKoeaagAFuAmhF=tS0DU4-A@mail.gmail.com>
References: <X9hHoQcZ11pBtgnz@paquier.xyz>
<20201215031902.GB14596@momjian.us>
<20201215190909.GK16415@tamriel.snowman.net>
<CAC0GmyyCqGrP7GpZCzGyJQZPqKBLJr9Nyqr5Q6Tdzy_UmJ96jg@mail.gmail.com>
<20201216001228.GC14807@momjian.us>
<CAC0Gmyy7QCvh4ey-e_XXYCHDEmaKKoeaagAFuAmhF=tS0DU4-A@mail.gmail.com>
On Wed, Dec 16, 2020 at 06:07:26PM +0000, Alastair Turner wrote:
> Hi Bruce
>
> On Wed, 16 Dec 2020 at 00:12, Bruce Momjian <bruce@momjian.us> wrote:
> >
> ...
> >
> > The second approach is to make a new API for what you want....
>
> I am trying to motivate for an alternate API. Specifically, an API
> which allows any potential adopter of Postgres and Cluster File
> Encryption to adopt them without having to accept any particular
> approach to key management, key derivation, wrapping, validation, etc.
> A passphrase key-wrapper with validation will probably be very useful
> to a lot of people, but making it mandatory and requiring twists and
> turns to integrate with already-established security infrastructure
> sounds like a barrier to adoption.
Attached is a script that uses the AWS Secrets Manager, and it does key
rotation with the new pg_altercpass tool too, just like all the other
methods.
I am not inclined to add any more APIs unless there is clear value for
it, and I am not seeing that yet.
> > ...It would be
> > similar to the cluster_passphrase_command, but it would be simple in
> > some ways, but complex in others since we need at least two DEKs, and
> > key rotation might be very risky since there isn't validation in the
> > server.
> >
>
> I guess that the risk you're talking about here is encryption with a
> bogus key and bricking the data? In a world where the wrapped keys are
> opaque to the application, a key would be validated through a
> roundtrip: request the unwrapping of the key, encrypt a known string,
> request the unwrapping again, decrypt the known string, compare. If
> any of those steps fail, don't use the wrapped key provided.
> Validating that the stored keys have not been fiddled/damaged is the
> KMS/HSM's responsibility.
OK, but we already have validation.
> >... I don't think this can be accomplished by a contrib module, but
> > would actually be easy to implement, but perhaps hard to document
> > because the user API might be tricky.
> >
>
> If integration through a pipeline isn't good enough (it would be a
> pain for the passphrase, with multiple prompts), what else do you see
> an API having to provide?
The big problem is that at bootstrap time you have to call the command
at a specific time, and I don't see how that could be done via contrib.
Also, I am trying to see value in offering another API. We don't need
to serve every need.
> > I think my big question is about your sentence, "A key feature of these
> > key management approaches is that the application handling the
> > encrypted data doesn't get the KEK, the HSM/KSM passes the DEK back
> > after unwrapping it." It is less secure for the HSM to return a KEK
> > rather than a DEK? I can't see why it would be. The application never
> > sees the KEK used to wrap the DEK it has stored in the file system,
> > though that DEK is actually used as a passphrase by Postgres. This is
> > the same with the Yubikey --- Postgres never sees the private key used
> > to unlock what it locked with the Yubikey public key.
>
> The protocols and practices are designed for a lot of DEKs and small
> number of KEK's. So the compromise of a KEK would, potentially, lead
> to compromise of thousands of DEKs. In this particular case with 2
> DEKs wrapped by one KEK, it doesn't sound like much of a difference, I
> agree. From an acceptance and adoption point of view, I'm just
> inclined to use the security ecosystem in an established and
> understood way.
Right, if there were many DEKs I can see your point. Using many DEKs in
a database is a big problem since so many parts are interrelated. We
looked at per-user or per-tablespace DEKs, but found it unworkable. We
use two DEKs so we can failover to a standby for DEK rotation purposes.
I think for your purposes, your KMS DEK ends up being a KEK for
Postgres. I am guessing most applications don't have the validation and
key rotation needs Postgres has, so a DEK is fine, but for Postgres,
because we are supporing already four different authentication methods
via a single command, we have those features already, so getting a DEK
from a KMS that we treat as a KEK seems natural to me.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Attachments:
pass_aws.sh (application/x-sh, 1.1K) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bruce@momjian.us, minion@decodable.me, sfrost@snowman.net, michael@paquier.xyz, masahiko.sawada@2ndquadrant.com
Subject: Re: Proposed patch for key managment
In-Reply-To: <20201216184257.GA4527@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox