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 surface. 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 branch. 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. -Phil
signature.asc
Description: Digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users