This is nice to see, it is a bit sad to see that bectl may not launch with support with separate boot pools (affecting users with a boot pool and an encrypted root pool) but I understand Allan’s point about consistency between the snapshots. Although it seems that native encryption in OpenZFS is coming along nicely for FreeBSD-current which should help the situation, just doesn’t seem to play nice if you also use dedup in ZFS.
New installations of FreeBSD 12.0-RELEASE (when it comes out) should not need a separate boot pool. But, yeah, systems upgrading to 12 from 11 may have a separate boot pool. I’d argue that with how awesome 12 is shaping out to be, a fresh reinstallation would be a good idea.
The OpenZFS native encryption implementation may suffer from the same types of watermarking vulnerabilities that plague the Oracle ZFS implementation. It would be best to stick with geli until the native crypto receives more cryptanalysis.
For the FreeBSD 12.0-RELEASE: definitely agree once it’s out a reinstall maybe worth considering, it’s just down to how well the encrypted pool support will work (I have not tried FreeBSD 12-ALPHA2 yet so I can’t say).
As for the OpenZFS native encryption, my take on the discussion in the linked mailing list thread is that the watermarking attack stems around how deduplication works in ZFS, so if you don’t need the dedup feature then it shouldn’t be as susceptible to watermarking vulnerabilities. Definitely something that needs heavy testing to be validated. Otherwise yes if you need/want dedup enabled on your encrypted pool, or don’t want to take the risk that it may still in fact be vulnerable, then for now sticking with geli would be wise, I was just saying that progress seems to be coming along nicely on that front.
Yup. There’s also potential attacks when compression is enabled. So, if you enable native encryption, you’ll want to disable both dedup and compression. These kinds of situations are why I prefer to be a bit more cautious in adoption. I think we need multiple cryptographers analysing this from multiple angles.
This is nice to see, it is a bit sad to see that
bectlmay not launch with support with separate boot pools (affecting users with a boot pool and an encrypted root pool) but I understand Allan’s point about consistency between the snapshots. Although it seems that native encryption in OpenZFS is coming along nicely for FreeBSD-current which should help the situation, just doesn’t seem to play nice if you also use dedup in ZFS.New installations of FreeBSD 12.0-RELEASE (when it comes out) should not need a separate boot pool. But, yeah, systems upgrading to 12 from 11 may have a separate boot pool. I’d argue that with how awesome 12 is shaping out to be, a fresh reinstallation would be a good idea.
The OpenZFS native encryption implementation may suffer from the same types of watermarking vulnerabilities that plague the Oracle ZFS implementation. It would be best to stick with geli until the native crypto receives more cryptanalysis.
For the FreeBSD 12.0-RELEASE: definitely agree once it’s out a reinstall maybe worth considering, it’s just down to how well the encrypted pool support will work (I have not tried FreeBSD 12-ALPHA2 yet so I can’t say).
As for the OpenZFS native encryption, my take on the discussion in the linked mailing list thread is that the watermarking attack stems around how deduplication works in ZFS, so if you don’t need the dedup feature then it shouldn’t be as susceptible to watermarking vulnerabilities. Definitely something that needs heavy testing to be validated. Otherwise yes if you need/want dedup enabled on your encrypted pool, or don’t want to take the risk that it may still in fact be vulnerable, then for now sticking with geli would be wise, I was just saying that progress seems to be coming along nicely on that front.
Yup. There’s also potential attacks when compression is enabled. So, if you enable native encryption, you’ll want to disable both dedup and compression. These kinds of situations are why I prefer to be a bit more cautious in adoption. I think we need multiple cryptographers analysing this from multiple angles.