Incidentally, just to put this whole mess into perspective, (and top-posting, because the text has gotten too long) the current wisdom is still that you should _not_ put LUKS on FLASH storage in the first place because that is a very hard to quantify risk. You should put it on classical spinning disk where an overwrite goes to the same sector as the original data. I bet no installer gives that warning to users in the first place. I find it a bit sad that the false god of performance seems to trump everything, and that its disciples are so blind not to even give warnings anymore what potentially negative effects folowing their creed has. Specrte and Meltdown are indeed nice examples why that can backfire damatically. Security, like most good engineering, is about redundancy. You cut a bit here and a bit there and suddenly you are nacked. Not good at all. Regards, Arno On Sun, Feb 03, 2019 at 15:23:42 CET, Michael Kjörling wrote: > 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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
