[PATCH] NEWS: cleartext indexing

[Daniel Kahn Gillmor]

On Mon 2017-10-30 08:46:12 -0400, Antoine Beaupré 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.
   

> 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-protection-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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20171030/6a6857f4/attachment.sig>