From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 8F3D16DE0BA5 for ; Mon, 30 Oct 2017 08:48:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YASfNHHXkcdP for ; Mon, 30 Oct 2017 08:48:00 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by arlo.cworth.org (Postfix) with ESMTP id 7CBD06DE0B64 for ; Mon, 30 Oct 2017 08:48:00 -0700 (PDT) Received: from fifthhorseman.net (p578E653F.dip0.t-ipconnect.de [87.142.101.63]) by che.mayfirst.org (Postfix) with ESMTPSA id E199DF99A; Mon, 30 Oct 2017 11:47:59 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8C7002063B; Mon, 30 Oct 2017 16:47:52 +0100 (CET) From: Daniel Kahn Gillmor To: Antoine =?utf-8?Q?Beaupr=C3=A9?= , notmuch@notmuchmail.org Subject: Re: [PATCH] NEWS: cleartext indexing In-Reply-To: <8760b4a3cs.fsf@curie.anarc.at> References: <20171022153634.14802-1-dkg@fifthhorseman.net> <8760b4a3cs.fsf@curie.anarc.at> Date: Mon, 30 Oct 2017 16:47:49 +0100 Message-ID: <87she0bpsq.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:48:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon 2017-10-30 08:46:12 -0400, Antoine Beaupr=C3=A9 wrote: > On 2017-10-22 11:36:34, Daniel Kahn Gillmor wrote: >> + Note that the contents of the index are sufficient to roughly >> + reconstruct the cleartext of the message itself, so please ensure >> + that the notmuch index itself is adequately protected. DO NOT USE >> + this feature without considering the security of your index. > > Could we expand on what those security options could be? Full disk > encryption? Or is there some way to PGP-encrypt the index and have it > decrypted on the fly? This is deliberately out of scope of the series -- i don't want this series to introduce notmuch-specific index encryption. Though if someone wanted to propose that i'd be happy to review it; fwiw, i have looked at a few deterministic mail index encryption schemes, and i'm not convinced that they meet any realistic threat model. But yes, my basic assumption is that people who care will keep their index on an encrypted filesystem, or at least on a filesystem that sits atop an encrypted block device layer. I don't know whether it's relevant if the encryption layer is "full-disk" or not. > Security, in this context, seems a little broad... I do have a antsy > feeling at decrypting all my private emails in a cleartext database > without additional measures. I'd sure love to see this notion expanded > here somehow. expand away! I'd be interested in reading your detailed thoughts on this. My basic rationale is: * i find myself not encrypting some e-mails because encrypted e-mails are too hard to use. in particular, they're hard to search through, and they are expensive to render. ("where was the address of that restaurant again? if only i had sent it in cleartext...") * the result is that i either send those mails in the clear (leaking the cleartext irrevocably), or i move my communications off of e-mail (typically to platforms on which i have even less control than e-mail). * This is actually a messaging security *anti-pattern*, and i've observed it in someone who takes communications confidentiality seriously (myself). * furthermore, it harms the ability for a conscientious sender to produce encrypted e-mail by default, because they're likely to be concerned about the same usability obstacles on the receiver's side. * making the use of encrypted e-mails more fluid and accessible should actually increase the total amount of encrypted mail, providing more protection in general. * the steps you need to take to secure your cleartext index are similar (though not congruent) to the steps you need to take to secure your MUA itself (endpoint-level security hardening). If you aren't already taking basic steps to protect your endpoint, it's not clear to me that keeping encrypted messages out of your index protects them significantly against a motivated attacker. I'd love to talk more at some point about dynamic or scoped access to a subsets of an encrypted filesystem (i.e. limiting access to your cleartext index so that it's *only* available to your MUA, and not to other programs running as your user account). Hopefully this series will trigger that as an additional discussion, though, rather than block on it. let's make encrypted e-mail as usable as cleartext e-mail (or as close to it as possible) to protect more communications overall. =20=20=20 > By the way, I have similar concerns about the autocrypt approach, which > goes even further and says private key material should not be protected > by a password at all: > > http://autocrypt.readthedocs.io/en/latest/level1.html#secret-key-protecti= on-at-rest > > It would be interesting to explain the rationale around those decisions > (which autocrypt does) and possible safeguards that mitigate those > issues (which autocrypt doesn't). Yes, we should have this discussion, but i don't think the notmuch mailing list is the right place for it. Feel free to come talk it over on the autocrypt list! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAln3SaUACgkQFJitxsGS MjcjDQ//eVHwCdNoIcY9xq/vh2Jp5E0rJKYS4fJLVyw/70abiQtVbhqHPec+LaBx PuQAX1s0w5WbjUds92BacnyyXKde5sU6t+6bc5pfL/6wb+onNtgDDf9OEgnQZktS RVIgYrOMR5REYzJaLSGv225ccWaDPWIbcfczKG4N232TMI7LElaREdMGwHPkjOoR ZA6wgKBNUvhe5yG7NLbQ6M9phQEWAbSIqpdTHjrL2lqpgABo6dXVFldzzFCUySGw g4N+t9RrW43ZFHoAly7lD98/iusXXaqb9DajBJhlnjYYFiw4naW8LIDBc9w4hOGb N3JRMUAWrTkwbgOUxBsb68U/ysdhm9tmA3UFlctljuydLcbcGmqJ39GPF4Ao5Uty gjDJGbFidSoq+a3j4zwZrAouHNffUltVPRMnJp1G2TeyrciGcFWvNlfBS4EHShbD 3mlrwmhdsgSJGYErJ+A64MVOARdNnLz86wjEI4SgQadGEWvFNygN5IoqU59SpQH1 omrUz7vVCbEE+GYIGSHXV0WQM/C3Fls+k05ZcFmykayfSH4BfreSZT/gDbWlAV6W w7r0CIGhSPPmpWHc8gHGHmxG2upiWKjbInsplyGS29C3yWVdwvVi2Puj+L9kTAUd iTkZXgtEN6k+UD4Qoi3boQLPSCX3ZHB6FKHigpoXpt6VBBzup+c= =mZcK -----END PGP SIGNATURE----- --=-=-=--