Faced with such a situation how should academic researchers behave? Should they avoid sensitive targets where the discovery of flaws would have more than simply academic consequences? Or should they home in on targets of this type, taking the view that the sooner we know the weaknesses, the sooner they will be rectified? If they choose the former path and do find a flaw, what is the best route to publicize their findings? After all, the dictum “publish or perish” was never more true for academics than it is today, with enormous pressures on them to produce high-impact research. What then is the best way to advise interested parties in industry and government so they can react? How can these parties even be identified? Is it a good idea to attempt to generate press headlines so as to spread the news as quickly as possible, or would this simply smack of irresponsible scare mongering? And what is the role of the press in all this?
These are all important questions to which there is no clear cut simple ‘correct’ answer. However, we will describe one way that a balance can be struck between the competing interests of academics (wishing to publish their findings) and other parties needing to react to news of a flaw (by deploying patches, updating systems, and so on).
The case study that we describe next is based on our own recent experiences in working on IPSec, a set of secure protocols standardized by the Internet Engineering Task Force (IETF). IPSec is used for building virtual private networks to provide secure communications over untrusted networks. Today it is widely deployed in operating systems and networking hardware. Unfortunately, the IPSec standards are notoriously complex with many, many configuration options possible. In the Information Security Group (ISG) at Royal Holloway, we found attacks against the Linux kernel implementation of IPSec in a particular configuration, widely known as “encryption-only”. Our attacks showed this mode to be completely insecure in the Linux implementation. And these were not just “attacks on paper”: we wrote an attack client and demonstrated the attacks in the laboratory with a realistic network set-up and operating conditions.
Naturally, we then asked ourselves the questions: What is the real-world impact of our attacks, and how should we spread the news? Even answering the question of whether the encryption-only mode was in wide use or not was not simple. The IETF standards clearly advise against using it, and yet the same standards mandate that this mode be supported by implementations! We found several on-line configuration guides for IPSec that showed how to configure IPSec in encryption-only mode in a step-by-step manner. Industry contacts also suggested that this mode might well be in fairly widespread use. However, it was not even clear at that point (in early 2005) whether our attacks would work against other implementations.