Re: Proposed patch for key management

Hi Bruce

On Mon, 4 Jan 2021 at 18:23, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> On Fri, Jan 1, 2021 at 06:26:36PM +0000, Alastair Turner wrote:
> > After the long intro, my question - If using a standard format,
> > managed by a library, for the internal keystore does not result in a
> > smaller or simpler patch, is there enough other value for this to be
> > worth considering? For security features, standards and building on
> > well exercised code bases do really have value, but is it enough...
>
> I know Stephen Frost looked at PKCS12 but didn't see much value in it
> since the features provided by PKCS12 didn't seem to add much for
> Postgres, and added complexity...

Yeah, OpenSSL 1.1's PKCS12 implementation doesn't offer much for
managing arbitrary secrets. Building a reasonable abstraction over the
primitives it does provide requires a non-trivial amount of code.

> ... Using GCM for key wrapping, heap/index
> files, and WAL seemed simple.

Having Postgres take on the task of wrapping the keys and deriving the
wrapping key requires less code than getting a library to do it, sure.
It also expands the functional scope of Postgres, what Postgres is
responsible for. This isn't what libraries should ideally do for
software development, but it's not uncommon and it's very fertile
ground for some of the discussion which has dogged this feature's
development.

There's a question of whether the new scope should be taken on at all.
Fabien expressed a strong opinion that it should not be earlier in the
thread. Even if you don't take an absolute view on the additional
scope, lines of code do not all create equal risk. Ensuring the
confidentiality of an encryption key is far higher stakes code than
serialising and deserialising the key which is being secured and
stored by a library or external provider. Which is why I like the idea
of having OpenSSL (and, at some point, nss) do the KDF, wrapping and
storage bit, and have been hacking on some code in that direction.

If all that Postgres is doing is the serde, that's also something
which can objectively be said to be right or wrong. Key derivation and
wrapping are only ever "strong enough for the moment" or "in line with
policy/best practice". Which brings us to flexibility.

> There is all sorts of flexibility being proposed:
>
> * scope of keys
> * encryption method
> * encryption mode
> * internal/external
>
> Some of this is related to wrapping the data keys, and some of it gets
> to the encryption of cluster files. I just don't see how anything with
> the level of flexibility being asked for could ever be reliable or
> simple to administer,...

Externalising the key wrap and its KDF (either downward to OpenSSL or
to a separate process) makes the related points of flexibility
something else's problem. OpenSSL and the like have put a lot of
effort into making these things configurable and building the APIs
(mainly PCKS11 and KMIP) for handing the functions off to dedicated
hardware. Many or most organisations requiring that sort of
integration will have those complexities budgeted in already.

>... and I don't see the security value of that
> flexibility. I feel at a certain point, we just need to choose the best
> options and move forward.
>
> I thought this had all been debated, but people continue to show up and
> ask for it to be debated again. At one level, these discussions are
> valuable, but at a certain point you end up re-litigate this that you
> get nothing else done. I know some people who have given up working on
> this feature for this reason.

Apologies for covering the PCKS12 ground again, I really did look for
any on-list and wiki references to the topic.

> I am not asking we stop discussing it, but I do ask we address the
> negatives of suggestions, especially when the negatives have already
> been clearly stated.

The negatives are increasing the amount of code involved in delivering
TDE and, implicitly, pushing back the delivery of TDE. I'm not
claiming that they aren't valid. I was hoping that PCKS12 would
deliver some benefits on the code side, but a bit of investigation
showed that wasn't the case.

To offset these, I believe that taking a slightly longer route now
(and I am keen to do some of that slog) has significant benefits in
getting Postgres (or at least the core server processes) out of the
business of key derivation and wrapping. Not just the implementation
detail, but also decisions about what is "good enough" - the KDF
worries me particularly in this regard. With my presales techie hat
on, I'm very aware that everyone's good enough is slightly different,
and not just on one axis. Using library functions (let's say OpenSSL)
will provide a range of flexibility to fit these varied boundaries, at
no incremental cost beyond the library integration, and avoid any
implementation decisions becoming a lightning rod for objections to
Postgres.

Regards
Alastair