Position Paper : Security and Simplicity

The last several months have raised public awareness of the extent of Internet monitoring by governments. The obvious defense is to use more cryptography, and in particular end-to-end encryption. This is done all too seldom, which in turn raises the question of why: why do so few sites, users, and protocols employ end-to-end encryption? Is there something that standards bodies such as the IETF and W3C can do? At this point, the problem is probably not the basic protocol. Most standard protocols have encrypted variants, whether on a separate port (e.g., IMAP [7] on port 143 unencrypted or 993 encrypted) or via an explicit request to start encryption (e.g., STARTTLS for SMTP [6]). (Some vendor-proprietary protocols do not have encrypted variants, but there’s not much a standards body can do about that.) Sometimes, the issue is cost, whether in CPU resources or in user latency. TLS [14], for example, requires several extra round trips; if the server is located halfway around the world from the user, the laws of physics set a lower bound on connection startup time. (Increasing the speed of light is apparently out of scope for both the the IETF and the W3C.) At this point, however, this is likely not the real issue. Sites that are large enough that they have significant numbers of users on other continents are probably using distributed data centers anyway. I assert that the underlying problem is protocol complexity; this in turn tends to manifest itself as implementation complexity. Quite simply, it is too hard for most site to configure encryption for most services because the system administrator doesn’t understand the choices and/or because they’re too hard to configure. This in turn suggests an appropriate response by the IETF and the W3C: simplify. Going forward, eliminate unneeded choices, frills, buttons, knobs, widget, and tweaks from security protocol designs; looking back, issue documents describing dead-simple default settings for important protocols like TLS and IPsec [10]. Vendors can then configure systems to match these defaults, resulting in a zero configuration experience for most sites. Yes, some sites will have different needs; these, though, tend to have more sophisticated personnel, and can spend the time and effort necessary to understand the options. In a few situations, new auxiliary protocols can be designed to simplify the design underlying protocols. The experience with SSH deployment in the late 1990s following the initial software release [22] is instructive. SSH was “fire and forget”; the cryptography just worked, with no administrator changes needed. System administrators responded enthusiastically. They may not have taken advantage of all of the software features, but for the most basic functionality—enabling secure remote login—they needed to do nothing. It was even possible for vendors to ship systems where SSH worked out of the box. That deployment strategy has been somewhat problematic [4], but that was an implementation failure, not a failure of the basic design. The remainder of this paper looks at several specific, important cases: IPsec and IKE, PKIX, and email. For lack of space, we omit discussion of DNSSEC, TLS, etc., but the same principles apply.