On 2017-10-30 16:47:49, Daniel Kahn Gillmor wrote:
> 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.
I think that assumption should be made clear in the documentation,
because "security of your index" means nothing to me. Explicitly mention
FDE as an example may be a good start.
>> 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.
Frankly, I don't have a good solution for this. I was thinking that
there may be a way to just encrypt the whole notmuch database with gpg
and decrypt it on the fly as needed, but that's probably a ludicrous
idea.
> 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.
So I hear all those arguments and mostly agree with them. That's the
"rationale about the decision" part, what I'm missing is the "mitigation
strategies". What I'm hearing is simply "use FDE", but I already do that
and I don't feel it brings much added security.
Having my emails encrypted adds another layer of security to that
content. FDE is good for data "at rest", e.g. when i travel with my
laptop. But when my laptop is opened and running, I like to think that a
part of it isn't accessible without the security layers behind PGP and
actual human confirmation. I don't feel that FDE brings that level of
security because "at rest" means "when the computer is shutdown" not
"when I'm not using the thing", unfortunately.
Now, I understand there may be no solution to this. But shifting the
burden of "secure this" to the user doesn't seem fair in this
context. We should clearly expose this as a compromise that the user
must be ready to take, not just be left as an exercise to the reader,
because there may be *no* solution.
In other words, what I think you are proposing with this patchset is to
consider PGP email encryption as a end to end encryption mechanism, but
*not* as a "at rest" encryption mechanism. I think that's a tradeoff I
may be ready to make, but at least it needs to be explicitly stated.
I am also not sure if it's the best way to implement such a
tradeoff. Why not simply decrypt the actual email on delivery and store
them in cleartext if you're going to have a cleartext copy on the side
anyways? That would seem like a much simpler solution to the problem
you're trying to solve here...
> 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).
Yeah, that's definitely something that's missing from Linux
systems. Android also suffers from that problem, even though it really
tries hard to keep data from being shared between applications. This is
better explained by Matt Green here:
https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/
But basically, iOS encrypts file per app, not per disk, so that app A
doesn't have the crypto key material to decrypt data from app B at
all. This is a fundamentally different principle than the way we do
encryption now in Linux, and would require a fundamentally different
approach to a lot of things for this to work at all on our
workstations.
> 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.
I definitely don't mean to block this. But I would like to see some
changes to the documentation to better explain those trade-offs, even if
it means just linking to this discussion. :)
>> 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!
Sure - I'll actually read the darn thing before commenting further
though. :p
Thanks for bringing this up, I hope this leads to a fruitful
discussion. :)
A.
--
À force de ne jamais réfléchir, on a un bonheur stupide
- Jean Cocteau
_______________________________________________
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch