> On Mar 14, 2017, at 12:54 PM, Nico Williams <n...@cryptonector.com> wrote: > > On Tue, Mar 14, 2017 at 12:32:10PM -0700, Russ Allbery wrote: >> "Henry B (Hank) Hotz, CISSP" <hbh...@oxy.edu> writes: >>> Shut down all daemons on the master. >> >>> hprop --decrypt --stdout | hpropd --stdin >> >>> Restart all daemons. >> >> You probably also want to shut down incremental propagation while you do >> this. I think this should force a full resync when the slaves reconnect, >> but it would be a good idea to thoroughly test the replication behavior in >> a test realm before doing this in a production realm. I forget how it >> deals with a complete database reload; I think it's supposed to do >> something sane, but that would be the component that I would worry about. > > Good point, but actually restarting the daemons does not force a full > resync. You have to remove the iprop log file (on the master and/or the > slaves -- either works) to force a full resync.
True. iprop will do a full download if the slave wants changes from a version older than the master has a record of. ipropd-master is a daemon, so I stand by my original statement. ;-) >> Note that you will need to manually copy the new master key to the slaves >> before they'll be able to replicate. Also don't forget to keep the old >> master key around for the length of your backup retention so that you >> don't invalidate your backups. > > If you're not storing the master key on a different disk anyways, and > maybe even if you are, I would recommend just not encrypting the HDB at > all. As with MIT, only the principals' keys are encrypted, which leaves > you subject to cut-n-paste attacks by, e.g., your backups operator. > > You should separately encrypt the backups/dumps. Probably, but encrypting the key material separately doesn’t seem like a bad thing. > Even if we could put the master key in a hardware token, that would not > be sufficient to make the keys that much more secure. Off-topic, but I agree. A lot of people are deploying HSMs believing they will solve problems they won’t. > The only case that KDB/HDB encryption gets you more security is where > it's easier to steal the disks than the whole system, and you either > store the master key on a disk that's inside the system or you type it > in when the daemons start. With modern kit that's just not the case, so > you might as well not encrypt the KDB/HDB. (MIT doesn't give you the > option; Heimdal does.) > > Nico > -- Personal email. hbh...@oxy.edu
