A postmortem on Efail

Phil Pennock gnupg-users at spodhuis.org
Sun May 20 22:28:13 CEST 2018

On 2018-05-20 at 02:26 -0400, Rob J Hansen wrote:
> https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08

Excellent post.  I favor breaking backwards compatibility and including
in the shipped README a description of "The conditions under which we
anticipate future backwards compatibility breaks".

Maintaining code, with the added code-paths, for handling obsolete
crypto has a cost.  Rarely exercised code-paths are security attack

I favor:

1. Branch GnuPG 1.x, remove all ability to encrypt or generate
   signatures, have something like "gpgv" but able to decrypt too (so
   still needs access to private keys).
   Call it `gpg-legacy-reader`.  The name makes it clear that future
   updates won't add new crypto support (until such time as something
   else has to be declared legacy).
   Explicitly state that the legacy reader must not be automatically
   used in an online mode which enables oracles and that timing attacks
   are out-of-scope.  Simplify.  Do not support people deploying this to
   untrusted hardware platforms or VMs where they need to defend against
   other users/occupants.  This should be a last-resort tool,
   invoked/triggered manually.

2. Drop all support, always, for non-MDC and other ancient modes,
   algorithms and packet formats from GnuPG.  Simplify the code-base,
   reduce the burden on the maintainers for the actively maintained

3. _Possibly_ consider an API in gpgme to trigger using
   gpg-legacy-reader behind the scenes, to make it easier for
   mail-clients to have a Big Red Decrypt Button to deal with ancient
   crap.  Make it clear that this MUST NOT be automatically used and
   that the user should be prompted with warnings of the danger.

4. Get together actual MUA maintainers who are users of the GnuPG
   code-base in a mailing-list and hammer out details of "what should be
   done about old mail".  Cryptographers have long said to decrypt
   inbound mail and re-encrypt it to a storage key, which can
   periodically be rotated, but AFAIK mail-clients don't have sane ways
   to do this.  There's no handling of recording verification state of
   things such as DKIM/ARC on the _original_ message in such a way that
   it could be used in future; perhaps a client signing key for a new
   header, only used to add to headers in the mailstore?  Without all
   the need for canonicalization, could be much simpler than DKIM.
   There's no tooling/expectations around lifecycle of reencryption when
   using open protocol mailstores via IMAP, there's no discussion of key
   management and recovery, there's no discussion of impact upon
   backups.  Instead, we have a lot of talking at the "nobody should do
   that" level and no contributions to actual practices to keep people
   from having to do "that".  It's time for this to change.
   I don't know if the MTA side can do _anything_ to help here, but if
   there's anything sane the MTA side can do to help, I can work to get
   Exim doing it.

If there's anything I can do to help, please let me know.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 996 bytes
Desc: Digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180520/576c10ac/attachment.sig>

More information about the Gnupg-users mailing list