A postmortem on Efail
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:
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
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,
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...
Size: 996 bytes
Desc: Digital signature
More information about the Gnupg-users