EFAIL is the name given to a series of vulnerabilities that affect two end-to-end email encryption protocols: OpenPGP and S/MIME . We chose this example not because it is representative of a usual vulnerability disclosure – it is not. We chose it rather because the controversies around it revealed various areas of frictions that highlighted some general disagreements regarding the management of vulnerability disclosure. We unfold the EFAIL disclosure process through four ethnographic descriptions.
For a few days in May 2018, most the attention of the IT security crowd seemed to be devoted to an enigmatic announcement released jointly by a team of researchers led by Professor Sebastian Schinzel and the Electronic Frontier Foundation (EFF): on May 13, 2018, at 11pm (in Germany), Schinzel tweeted that his team found a series of critical vulnerabilities in email encryption protocols against which there were no reliable fixes available1. The tweet announced that the full details will be made public two days later. The tweet also provided a link to an EFF’s blog post with some advice to mitigate this until it would be definitely fixed. Following this announcement, many people started to debate about the issue itself on Twitter, in forums and mailing lists, even though the full details were not yet available. The day after the announcement and prior to the planned release date, details about the vulnerability leaked. What followed was a chaotic situation that forced the EFAIL researchers to expedite the official disclosure of the full paper that had already be spread out. Several articles in specialist and generalist newspapers, websites and blogs were published immediately after, hyping even more the controversial issues about the nature of the vulnerabilities and how it has been disclosed.
The Internet Engineering Task Force (IETF) is the organization responsible for the standardization of many internet protocols including OpenPGP and S/MIME . A working group composed of volunteers is dedicated to defining and maintaining the standard during the trimestral 5-day IETF meetings or on the mailing list which is freely available online to anyone . There was no immediate reaction after the public disclosure but on June 30, 2018, an email called «AEAD mode chunk size» was sent to the mailing list and provided some technical thoughts about how to mitigate one specific issue of EFAIL. An asynchronous conversation started – mostly on a highly technical level – which happened only through emails involving many actors worldwide. This process lasted till May 2019 and resulted in the release of a new version of a part of the protocol which was later implemented in a lot of software and many digital libraries.
During that time, many other topics were discussed on this mailing list but interestingly, there were only very few explicit references to EFAIL. Instead, the vulnerabilities were scraped into a series of technical issues to be remediated separately, sometimes by different people. Interestingly, the tempo of what was done and exchanged through the IETF mailing list was not impacted by other manifestations of the vulnerability in the infosec community, like the Usenix presentation that took place in August 2018. The discussion happened predominantly amongst engineers and developers committed to finding a consensual solution to be implemented in various compatible yet competing products.
On August 16, 2018, in the Grand Ballroom VII–X of the Marriott Waterfront hotel in Baltimore, USA, Damian Poddebniak, on behalf of the EFAIL team, presented the EFAIL attack in front of an academic audience at the Usenix Security Symposium.
For the first time in public, the team deciphered the technicalities of the flaws they uncovered on the encryption protocols. According to the researchers, the paper was really well received by the academic community which was concerned by the technicality of the attack. In this plane, the EFAIL vulnerabilities can be seen as a formal object of study in computer science: this instance of EFAIL was assembled for an academic audience and the paper was a formal «proof of concept» of a new technique that the researchers called «malleability gadgets» (Poddebniak et al. 2018). As Schinzel himself told us, the Usenix paper, had to be «translated» to a more digestible format for developers and users (personal interview in Leipzig, 27.12.2018).
On December 28, 2018, at 8.50 pm, Professor Sebastian Schinzel got on the stage at the 35c3 wearing a tee-shirt with the logo of EFAIL.
The Chaos Communication Congress (CCC) takes place every year since 1984, a major event for all geeks and technology enthusiasts in Europe. Very different from the Usenix paper, this presentation was neither very formal nor too specialized and, in addition to the technical details, it also gave room to broader considerations such as the pervasive lack of privacy that affects emails and the misadventures of the disclosure process. Although Schinzel did not reveal any new issues concerning EFAIL, he took the opportunity to make some statements about the public disclosure process. He declared that whatever happens, he would henceforth stick to the rule of the 90-days delay because it was not helpful to give the developers more than 200 days to find a solution. The 90-days rule he referred to is an embargo that implies that a researcher who found a vulnerability would give 90 days to the developers to ship a patch before disclosing the research publicly. Even though 90 days are somehow arbitrary, it is a usual standard in practice in infosec that is supposed to give enough time for developers while at the same time putting them under pressure. During his talk, Schinzel also added that he would probably no longer release a warning statement prior to the publication of the vulnerability itself because it did not work and people did not understand his intentions well. Hence, among other things, this talk was intended to close the disclosure controversy that erupted after his initial tweet.