Comment on EFAIL

The EFAIL attack in a sentence: an encrypted message is injected with an unclosed html tag pointing to the attacker's domain, upon decryption the tag is rendered which also includes the decrypted message as part of the URL.

For the attack to succeed, the attacker must obtain a copy of an email encrypted for the victim, modify it, send it to the victim, the victim's email client must decrypt the message, ignore any decryption errors and load external resources. There are two elements to this attack, modification of encrypted messages and loading of external resources in emails. Having experience with analysing the specification and having audited a number of implementations, I will focus on the OpenPGP aspect of the attack.

OpenPGP introduced integrity protected (IP) messages through modification detection codes (MDCs) in 2000. Non-IP messages were left as part of the specification, even when it was updated in 2007, for legacy purposes and slow rate of adoption of integrity protected messages by implementors and users. How implementations of OpenPGP handles non-IP messages varies a lot. Some return errors, some returns the decrypted message along with a warning, and some treat non-IP the same as IP. This leaves it up to the invoking application to make the final security decisions.

Leaving it up to an email client to make an informed security decision based on flawed output is not reasonable. That said, external resources should not be downloaded by default in a modern email client, since that in itself is a privacy intrusion. The current OpenPGP specification is complex and is provably hard to implement correctly. It is in desperate need of modernization, restriction and clarification. Work on updating the specification started in 2015, but has been painfully slow.

The responsibility for handling the issue is threefold, foremost the OpenPGP specification, the OpenPGP implementations of the specification, and the email clients interacting with the implementations.

This is not the last issue we will see with the current OpenPGP specification. Hopefully this, and coming issues, will speed up development.