On Sun, Jun 16, 2019 at 02:10:23PM -0400, Stephen Frost wrote:
>Greetings,
>
>* Joe Conway (mail@joeconway.com) wrote:
>> On 6/16/19 9:45 AM, Bruce Momjian wrote:
>> > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
>> >> In any case it doesn't address my first point, which is limiting the
>> >> volume encrypted with the same key. Another valid reason is you might
>> >> have data at varying sensitivity levels and prefer different keys be
>> >> used for each level.
>> >
>> > That seems quite complex.
>>
>> How? It is no more complex than encrypting at the tablespace level
>> already gives you - in that case you get this property for free if you
>> care to use it.
>
>Perhaps not surprising, but I'm definitely in agreement with Joe
>regarding having multiple keys when possible and (reasonably)
>straight-forward to do so. I also don't buy off on the OpenSSL
>argument; their more severe issues certainly haven't been due to key
>management issues such as what we're discussing here, so I don't think
>the argument applies.
>
I'm not sure what exactly is the "OpenSSL argument" you're disagreeing
with? IMHO Bruce is quite right that the risk of vulnerabilities grows
with the complexity of the system (both due to implementation bugs and
general design weaknesses). I don't think it's tied to the key
management specifically, except that it's one of the parts that may
contribute to the complexity.
(It's often claimed that key management is one of the weakest points of
current crypto systems - we have safe (a)symmetric algorithms, but safe
handling of keys is an issue. I don't have data / papers supporting this
claim, I kinda believe it.)
Now, I'm not opposed to eventually implementing something more
elaborate, but I also think just encrypting the whole cluster (not
necessarily with a single key, but with one master key) would be enough
for vast majority of users. Plus it's less error prone and easier to
operate (backups, replicas, crash recovery, ...).
But there's about 0% chance we'll get that in v1, of course, so we need
s "minimum viable product" to build on anyway.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services