Re: Stashed session keys

[Jameson Graef Rollins <jrollins@finestructure.net>]

[-- Attachment #1: Type: text/plain, Size: 3736 bytes --]

On Wed, Oct 25 2017, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> Now that cleartext indexing is merged, let's add the ability to stash
> session keys!

I have reviewed and tested this series, and it seems solidly implemented
and very well motivated.  I have been using it regularly for a couple
weeks now and have found no issues with it's usage, and have noticed the
considerable speed up when viewing encrypted threads (as much as x8 for
show on a thread of just 8 encrypted messages).  I fully support it's
integration unconditionally.

It should be emphasized that this series is actually fairly critical for
good support of message encryption.  Without this series it's actually
possible to completely lose access to encrypted mail if one were to
rotate/replace their encryption key, which one might reasonably be
expected to do.  Without access to the original encryption key or the
message session key, there is no way to access the contents of an
encrypted message.  If, however, the session key is stashed in the
index, the original encryption key can be destroyed and the message can
still be accessed.  Daniel likes to think of this in terms of being able
to "delete" encrypted messages in the wild (via deletion of the original
encryption key) whereas I like to think of it in terms of preserving
access to received encrypted messages after key rotation.  Both benefits
hold, though, obviously.

>    +------------------------+-------+------+---------+------+
>    |                        | false | auto | nostash | true |
>    +========================+=======+======+=========+======+
>    | Index cleartext using  |       |  X   |    X    |  X   |
>    | stashed session keys   |       |      |         |      |
>    +------------------------+-------+------+---------+------+
>    | Index cleartext        |       |      |    X    |  X   |
>    | using secret keys      |       |      |         |      |
>    +------------------------+-------+------+---------+------+
>    | Stash session keys     |       |      |         |  X   |
>    +------------------------+-------+------+---------+------+
>    | Delete stashed session |   X   |      |         |      |
>    | keys on reindex        |       |      |         |      |
>    +------------------------+-------+------+---------+------+

I think these policies cover all potential use cases that I can see.
However, there will need to be further work on the UX to make things
flow more smoothly.

I've been using this series with index.try_decrypt set to 'true', which
causes encrypted messages to be indexed on new.  I do this because I
don't want to be bothered to manually initiate indexing of encrypted
messages.  However, since my mail retrieval and indexing happen in the
background, this has the unfortunate side effect that I am occasionally
presented with a gpg agent prompt at random unexpected times.  Ideally,
one would leave index.try_decrypt set to 'auto', and there would be an
easy/automatic way to prompt reindexing when the user is interacting
directly with their MUA.  I haven't decided what's the best way to do
that yet, but something like the following happening automatically at
inbox view might do the trick:

  notmuch reindex --try-decrypt=true (tag:inbox AND tag:encrypted)

Finally, I think it would be worthwhile to resolve the disparity between
the usage of "decrypt" and "try-decrypt" in the CLI and config options.
I'm not sure why we're using different terms in different contexts, even
though the meanings are essentially the same.  A follow-up patch series
changing "try-decrypt" -> "decrypt" would probably be in order.

But these are next steps.  The series in question here is absolutely
ready, and needed, as is.

jamie.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]