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 ABD036DE0B6D for ; Sat, 11 Nov 2017 15:31:41 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-0.428, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.972, T_RP_MATCHES_RCVD=-0.01] 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 CqTkq80hDrID for ; Sat, 11 Nov 2017 15:31:40 -0800 (PST) Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu [131.215.239.19]) by arlo.cworth.org (Postfix) with ESMTPS id 72A876DE02DD for ; Sat, 11 Nov 2017 15:31:40 -0800 (PST) Received: from smtp01.caltech.edu (localhost [127.0.0.1]) by smtp01.caltech.edu (Postfix) with ESMTP id 3A0E8A1547; Sat, 11 Nov 2017 15:31:40 -0800 (PST) X-Spam-Scanned: at Caltech-IMSS on smtp01.caltech.edu by amavisd-new Received: from finestructure.net (ip184-180-110-103.br.br.cox.net [184.180.110.103]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jrollins) by smtp-server.its.caltech.edu (Postfix) with ESMTPSA id 9A096A14E6; Sat, 11 Nov 2017 15:31:39 -0800 (PST) Received: by finestructure.net (Postfix, from userid 1000) id 0730F60317; Sat, 11 Nov 2017 15:31:39 -0800 (PST) From: Jameson Graef Rollins To: Daniel Kahn Gillmor , Notmuch Mail Subject: Re: Stashed session keys In-Reply-To: <20171025065203.24403-1-dkg@fifthhorseman.net> References: <20171025065203.24403-1-dkg@fifthhorseman.net> User-Agent: Notmuch/0.25.1 (https://notmuchmail.org) Emacs/25.2.1 (x86_64-pc-linux-gnu) Date: Sat, 11 Nov 2017 15:31:36 -0800 Message-ID: <87po8os887.fsf@ligo.caltech.edu> 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: Sat, 11 Nov 2017 23:31:41 -0000 --=-=-= Content-Type: text/plain On Wed, Oct 25 2017, Daniel Kahn Gillmor 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEtl0IW5QRe4ExYLZZ7TTOq+J7qrwFAloHiFgACgkQ7TTOq+J7 qrzFcBAAnUJM0utvCt51OFNJKW0rjg1mvWk8blC/qdAOMOVDoSxGxF7tvAs4wZve 3C+GJh1XLjm8+XnNWDgnAAYQaLOq6UvOchncUSG7PmIVqCWjq5q8Pty0C+mSqL17 YNIzI4lmGCxY7ZaMA/TWiaERfuWVUp75k7sPPTJ6BBKiX7kX8NrifNoSN8omOY6h zNC0WjBwr1tlTJXu1kagewyPsHGSVfjMJPuhcJ0inx6Y4eILFKdCKMCDfDWO1pUr 05yty83MsfySUEOvAuRN5Q2Sth8Fu9vhcKMuUt/yTGG6hcWGmnpOKplIUllEjYa2 YCYr0hn9/fYepaLiSG9+tWYt8kc+iWxEhFKHFyE2HKc9q3IBOOSeN3ljFIL+82fN V0sXBhkMBLY+wRL/49M9dmMpzp4eZHfFP3HtPGHBpUcNtaNbkFdAMTht/I+scjp/ UJX9dusFEV9baH/npT0ZAqw2Zs5ww9rMMOrvC5SxbtR2L0rS7tx2cFXsZH2NmeY7 4ZyrVHjn2NCAtOkJOLolKUN2vFAgARn03FBROizX3kWx2JixhDRvRKWxeOXkfxXW HeJs6Vgm8PhLfsObcQ35N/cu3fk/GXw8icsC7Aedsh5TSk1uWas0OjYhE5BPGHoq ptW4UxB2QPGqUKc4qaVlHND8kCES3szPT6EkvzVLMETv+64Vya0= =5osj -----END PGP SIGNATURE----- --=-=-=--