Securing Network Content

The goal of the current Internet is to provide content of interest (Web pages, voice, video, etc.) to the users that need it. Access to that content is achieved using a communication model designed in terms of connections between hosts. This conflation of what content you want to access with where (on what host) that content resides extends throughout current network protocols, and determines the context in which they offer network security. Trust in content – that it is the desired content, from the intended source, and unmodified in transit – is determined by where (from what host) and how (over what kind of connection) the content was retrieved. A user believes they are reading the news from the New York Times when they access it via a user-friendly name for the authoritative source of that news – www.nytimes.com; whether guessed, known, or obtained from a trusted directory (Google) in response to a few relevant search terms. Implicitly, they are also trusting that a) the DNS has given them a reliable indicator of where to find a host authorized to “speak for” the name they are interested in, b) they have actually made an HTTP connection to that host or its delegate (such as a content distribution network, or CDN) and c) that the content retrieved over that connection is unaltered by any unauthorized intermediary.1 A user accessing a higher-value resource, say their bank account, may do so with confidence only over a connection further authenticated by a cryptographic protocol such as TLS [10]. This gives them assurance that not only is the data coming from the intended source (as determined by the trust model for evaluating digital certificates built into their software client), and that it has not been tampered with in transit, but additionally that it may be protected from eavesdropping by encryption. This connection-focused approach to security inex-