On 31 Jan 2019 00:11 +0100, from jonas@xxxxxxxxxxxxxxx (Jonas Meurer): > I think, we should just adjust the docs of the Debian cryptsetup package > and explain to users that they should always give the 'discard' option > to new devices if they don't have a good reason to not do so (i.e. have > hidden volumes inside the volume, have to hide whether there's data > written to the volume or want to protect against access patterns being > leaked). I disagree. Certainly a note could be added that adding the 'discard' option can improve performance, and the choice to do so can be offered during interactive installation, _but_ with a clear warning that depending on the threat model, it may improve performance at the cost of security, and that those who desire the best security should leave discard disabled, whatever exact choice that means given the specific selection of choices provided. Frankly, people in general, even those who value security, in my experience have only the vaguest sense of an idea about threat modelling, even in the physical space (let alone digital). Those people are exactly the ones who are most likely to do something like turn on LUKS during system installation, set a reasonably strong passphrase (because they understand that turning on encryption improves security, and that a longer or more random passphrase equals better security) and _not_ understand or realize that they _also_ need to take active steps to turn off "discard". I doubt many people would even reflect on metadata leakage due to storage location patterns in use. And _they shouldn't need to_ consider such things; again, _reducing_ security should be the active choice, not _improving_ security, even if the specific threat seems somewhat far-fetched today. Spectre and Meltdown also seemed far-fetched, to the extent that such attacks were even considered, only a few years ago; now they (and their ilk) are on the minds of a lot of very smart people both trying to exploit them, and trying to mitigate them without completely ruining performance. The difference is, we didn't actually envision out-of-order speculative execution to leak information, since it was supposed to be purely internal to the CPU with no observable side effects; here, we can actually _see_ a benefit to the more secure choice (that of by default not allowing TRIM pass-through), in that it reduces metadata leakage. Metadata _is_ data, even when it's "only" metadata about metadata. It's turtles all the way down. In the words of BCP 188: > Those developing IETF specifications need to be able to describe how > they have considered [pervasive monitoring], and, if the attack is > relevant to the work to be published, be able to justify related > design decisions. This does not mean a new "pervasive monitoring > considerations" section is needed in IETF documentation. It means > that, if asked, there needs to be a good answer to the question "Is > pervasive monitoring relevant to this work and if so, how has it > been considered?" > > In particular, architectural decisions, including which existing > technology is reused, may significantly impact the vulnerability of > a protocol to PM. Those developing IETF specifications therefore > need to consider mitigating PM when making architectural decisions. > Getting adequate, early review of architectural decisions including > whether appropriate mitigation of PM can be made is important. > Revisiting these architectural decisions late in the process is > very costly. While Debian's installer defaults for LUKS hardly constitutes an IETF specification, I believe that the advice of BCP 188 is still worth heeding. > I see that the discard option has security implications. Absolutely. > Whether those are minor or major is debatable. My take on this is, that > the tradeoff is acceptable and for the vast majority of users > neglectable. On the other side, having fstrim working per default even > on encrypted volumes is a huge advantage. Such was, to a large extent, the reasoning also about speculative execution. Not so these days, _after_ someone figured out a way to exploit it as a weakness and turned the idea of doing so from a curiosity to a pretty big issue. -- Michael Kjörling • https://michael.kjorling.se • michael@xxxxxxxxxxx “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
