| Network Working Group | P. Hallam-Baker |
| Internet-Draft | Comodo Group Inc. |
| Expires: April 30, 2015 | October 27, 2014 |
PRISM-Proof Email Deployment Requirements
draft-hallambaker-prismproof-dep-01
This document describes previous efforts and their deployment legacy and the requirements for a successful email security infrastructure. A gap analysis is performed and the tasks divided into problems that are generally considered solved albeit possibly requiring improved execution and problems that may be regarded as research.
This division of the problem space into 'execution' and 'research' portions allows different groups of developers to address each independently and avoid unnecessary duplication of effort. A testbed for development and early adopter deployment that achieves this separation is described.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Establishing a ubiquitous infrastructure for end-to-end confidentiality, integrity and authenticity of email has been an unrealized goal of IETF security efforts for over two decades. This document examines the deployment legacy of these previous email security efforts with a view to identifying which parts may be adopted in a new email security scheme with only minor modification to improve execution and which limitations or deficiencies are better considered research.
This analysis results in a proposal for an email security research testbed which separates the parts of the infrastructure that researchers can adopt in their current form without modification from areas in which innovation is needed. It is hoped that dividing the problem in this fashion will enable the most effective use of developer resources permitting a developer with expertise in developing extensions for one email user agent to support all the research proposals based on the testbed and to a allow researchers using the testbed to support all the clients that have been enabled.
Recent events have renewed interest in email privacy and may present a fresh opportunity to deploy a comprehensive email security infrastructure. But even if the threat of a PRISM-class attack provides the necessary momentum to restart development efforts, any infrastructure developed must address the full range of email security concerns if it is to become ubiquitous.
The IETF has attempted to produce an email security scheme on six previous occasions:
Of these efforts, only S/MIME, DKIM and STARTTLS have achieved ubiquitous deployment to date while only OpenPGP has achieved ubiquity in mindshare. The resulting stalemate has lasted over a decade.
Attempting to revisit work previously attempted that has failed requires us to ask whether it is necessary to re-invent the wheel and whether a new attempt has better prospects for success. In order to answer such objections we must understand the reasons for the earlier failures.
The Internet has two 'killer applications'; email, and the Web. The Web has succeeded in establishing a comprehensive security infrastructure while email has failed.
The chief security infrastructure of the World Wide Web is SSL/TLS and the WebPKI. This security infrastructure presented a clear and immediate benefit to parties deploying SSL security, in particular the ability to use the Web for an important purpose not possible otherwise (the ability to accept credit cards). Secure email has a similar potential to enable the use of email for purposes not currently possible. For example the ability to remit electronic invoices and other transactional data in machine readable formats.
Another key element in the success of SSL/TLS is the ease of deployment (and to a lesser extent, development). To enable 'security' on a Web site, the system manager needs to do nothing more than obtain and install an X.509/PKIX certificate.
Finally, and perhaps most importantly, SSL/TLS places no burden on the end user. The end user need take no action whatsoever (although to be secure the end user should take notice of the security indicators provided). In contrast, use of S/MIME requires that each user obtain a certificate and renew it at regular intervals, typically a year. This is a significant burden on the end user. Sending an encrypted message requires the user first obtain the certificate of the intended recipient, a process that is hardly simple. Use of PGP requires the user to understand and navigate the Web of Trust.
One factor that made developing a security infrastructure for the Web considerably easier than developing an infrastructure for email is that efforts to add cryptography began within a few months of the first public release of the Web. Email was an established infrastructure before the (public) invention of public key cryptography and efforts to retrofit cryptography had to work within the constraints of what had already become a complex legacy infrastructure.
Another factor that makes email security a more difficult problem than Web security is that the basic unit of interaction in email is the individual user while Web security is provided at the level of the site.
A comprehensive email security infrastructure must meet a wide range of requirements, not all of which may be compatible. In the enterprise, the confidentiality provided by strong encryption may conflict with a security policy that requires all inbound email be scanned for potential malware.
At the time PGP and S/MIME were developed it was common to refer to 'Internet users'. Today the Internet has over 2.4 billion users and virtually every literate person in the developed world is an Internet user. It makes no more sense to refer to 'Internet users' as a distinct class of people as it would to refer to 'telephone users' or 'electricity users'.
A security infrastructure that can support a population that size must work as easily and reliably as the telephone and electricity infrastructures do. A security infrastructure that requires users think is not going to succeed.
A common mistake made in considering requirements is that prospects for deployment are improved by reducing requirements to the bare minimum. While this approach may reduce development costs it also reduces functionality and the potential value to adopters. Worse still is the approach in which the design team performs triage on the set of requirements before beginning the design work. While it is acceptable, possibly even inevitable that a design will not meet every requirement raised in the design process, parties considering adoption should know which requirements a design does not meet.
The discovery of PRISM-class attacks requires all aspects of a protocol to become transparent including the design process. If a legitimate requirement is raised during the development process it must be listed in the requirements document even if the final design does not address it.
One of the main reasons that SSL has succeeded despite the cost of using the WebPKI and OpenPGP has failed to become ubiquitous despite being free for use is that SSL presented a valuable commercial opportunity while OpenPGP did not.
The Internet has over 2.4 billion users and any infrastructure supporting such a userbase will inevitably incur maintenance costs. Even if those costs are a fraction of a cent per user, the aggregate cost is millions of dollars. In practice the inevitable need for some level of instruction and customer service means that the costs are likely to be rather higher.
The least effective security control is the one that is never used. An email security infrastructure can only become ubiquitous if using email securely requires no more effort than using it insecurely does.
Usability studies are difficult to perform well, security usability studies are even harder. A typical usability study is focused on the question most important to the manufacturer of a product: How to make a sale. Such studies are usually focused on the type of short term interactions a potential customer makes while deciding whether to buy rather than long term use. In particular there is a tendency to 'solve' a usability problem by hiding information from the user if it might cause concern.
Email has become an essential facility for most people in the modern world. Secure email is of no use to them if they cannot rely on being able to access their email or email archives.
Earlier attempts to provide email security were developed at a time when the Internet was a community of people. The modern Internet is both a community of users and also the communication medium that supports the vast majority of commercial and government activities.
Commercial and government use of the Internet have confidentiality needs that are distinct from the needs of private individuals. In particular an employee of a government or commercial entity my be acting in a personal or an official capacity.
These concerns give rise to the following requirements:
[[Enterprise-Access]
Confidentiality is not a binary quality. An email sent by alice@example.com to bob@example.net may be encrypted as follows:
TLS security only protects the confidentiality of messages during transport and is thus only a sufficient confidentiality control if we can be confident that transport security will be used on each of the three occasions the messages travel across the Internet and that the message will be acceptably secure when queued at the outbound server waiting for dispatch, on the inbound server at example.net and on any MUAs that Bob might be using that download and store a copy of the message.
Message layer security provides a more comprehensive confidentiality guarantee for the message contents but cannot provide protection for the routing information (aka meta-data) necessary to route the information over the public network. In the case of S/MIME and PGP, the confidentiality is further compromised by the odd decision to transmit message subject lines as plaintext.
Rather than considering TLS and Message Layer security to be competing alternatives, we should acknowledge the fact that both approaches are valuable and that we should encourage the use of both.
While the desire for confidentiality has been the traditional driver for Internet email security efforts (e.g. Pretty Good Privacy), it is far more likely that a user will suffer harm or economic loss as a result of an authenticity attack.
This morning I have three messages that have evaded my spam filter that are telling me that I need to reset my username and password. All three are fraudulent but appear identical in virtually every respect to the genuine messages that the purported senders have sent in the past.
Establishing a usable infrastructure for establishing the authenticity of email messages is as important and necessary as establishing a usable confidentiality infrastructure.
The Internet email system is based on the principle that all a user needs to send a message to another is to have an email sending account and to know the email address of the intended recipient. Any secure email infrastructure must recognize that same constraint.
Accordingly mechanisms are required that can:
Identity is and is likely to remain an ongoing research topic because it is this aspect of PKI that represents the interface between the online and offline worlds. All the rest of the cryptography and infrastructure is merely protocol and math. Identity cannot be reduced to mere math because it involves people and names.
Identity is not an objective truth and it is highly unlikely that research will arrive at a single definitive approach that is suited to all purposes and all times. Rather than deciding between the PKIX CA approach and the OpenPGP Web of Trust we sypport the use of both or a system that is capable of supporting both.
Identity has multiple dimensions. Even the simple system described gives rise to multiple identity requirements reflecting the different dimensions of trust:
One of the major lessons learned in the successful deployment of the World Wide Web in comparison to its rivals was the importance of allowing Web users to post pictures of their cats.
Unlike rival systems such as Hyper-G, setting up a Web client or server needed no system administration privilege or purchase order. Any user granted ordinary UNIX or VMS user privileges could set up a client or server. One unexpected consequence of this difference was that systems like Hyper-G were bought for a specific purpose and use for frivolous purposes such as pictures of cats was strongly discouraged. The Web in contrast, was a free for all. The only barrier to putting information on the Web was the willingness of someone to publish. As a result the fact that prior to the launch of Netscape Navigator in late 1994, Hyper-G had a far nicer, slicker client was irrelevant. The Web won the standards war in part because it won the content war: The Web had pictures of cute cats and Hyper-G did not.
For email security to succeed in deployment, users must be able to publish a key without first obtaining permission from their system administration. But this is a matter of convenience, not right.
The holder of a DNS domain name also has the right to control how their domain is used. If example.com is a bank, the bank has a security interest in telling potential relying parties to only trust credentials duly authorized by the bank itself. If bank employees find this to be inconvenient, they can use a different domain or register their own.
Previous efforts to develop an Internet email security infrastructure have left unsolved problems but what is more important is the much larger number of problems that may be fairly regarded as solved whether in actual running code or through obvious extensions. To deploy an secure email infrastructure that resists PRISM-class attack we should build on what works whetever that is adequate for our purpose and only revisit design decisions where unmet requirements demonstrate that further work is required.
One factor that complicates this pragmatic approach is the schism between S/MIME and OpenPGP which in addition to specifying two different trust management approaches, also specify two message formats, two key signing formats and two of everything else that might be required. In these cases the existence of deployed code is considered the deciding factor.
In particular adopting the S/MIME message and key formats as the base to work from makes it possible to build a system that allows many users to receive encrypted email using existing clients without modification. Working from the OpenPGP message formats does not. Therefore the S/MIME message formats are preferred over the OpenPGP formats but this particular design decision does not preclude the use of OpenPGP style 'Web of Trust' key validation.
The Testbed is designed to partition the solution space for secure email into two parts; 'execution' and 'research' so that development work can proceed independently on each part.
The interface between the two parts of the solution space is to be addressed by a Web Service protocol. Current best practice and the need to support a wide range of platforms including scripting environments strongly favors the adoption of a JSON/REST style syntax.
The Omnibroker Web Service is designed to meet this need in the context of TLS and the protocol has been designed to support discovery of peer-to-peer connections but has not yet been tested.
Omnibroker is built from two components, the JSON Service Connect (JCX) Protocol [I-D.hallambaker-wsconnect] which establishes and manages a secure authenticated connection between the client and service and the Omnibroker Query Protocol [I-D.hallambaker-omnibroker] which answers queries.
JCX is designed to provide a general facility that can be used in any Web Service and should be applicable without specific modification to address email. The query protocol is in theory designed to support establishing peer-to-peer connections but this has not been tested and the asynchronous nature of email may result in additional requirements being discovered.
Since email is currently insecure by default, a testbed that offers less than perfect end-to-end security is still a significant improvement. The email infrastructure has taken four decades to evolve to its current state. It will take some time to carry the legacy infrastructure to the desired state of security. In the near term it is much more important that an email user be able to exchange email with users of experimental trust infrastructures than achieve the end to end benefits they may be designed to offer.
One of the reasons that the Web succeeded while Ted Nelson's Xanadu failed is that the Web cut the right corners. HTTP does not offer the referential transparency or the integrated search that Nelson insisted was essential. But excluding those from HTTP made the problem of deploying network hypertext tractable and third parties offered tools and services to fill the gaps as soon as it became clear that the Web was approaching critical mass.
To make the problem tractable, the following simplifications are allowed:
Accepting these simplifications for short term expediency does not require them to be accepted as permanent concessions. I expect it to be possible to eliminate each of the simplifications except for the last as the testbed approaches a critical mass of users.
Performing trust chain discovery and validation end-to-end instead of end-to-end is a very different proposition. Performing trust chain discovery in particular is a task that is already delegated to a cloud based service in many moderately complex trust topologies as the success of SCVP demonstrates [RFC5055].
It might well prove to be the case that it is also desirable for at least some trust chain validation steps to be performed in the cloud by a service rather than at the relying application. Insisting that every trust chain validation step be performed end-to-end limits the scope of validation steps that can be applied using the techniques supported by and the data available to the client.
Transport security and message security serve distinct purposes and a comprehensive email security infrastructure should provide both forms of security on each and every message sent.
The last criteria is not currently supported by existing infrastructure. DANE [RFC6698] proposes one mechanism for validating the certificates using the DNSSEC trust hierarchy [RFC4033]. But this is only one mechanism and one that in its current form limits the verifier to a single root of trust.
MUAs should be capable of pinning TLS certificates presented by SUBMIT and IMAP services [I-D.evans-palmer-key-pinning] and instructing the outbound mail server to only forward a message over a TLS secured channel. These precautions enable a MUA that has received security policy information for the intended target mail server to relay it to the outbound server which may not have access to that source.
Secured mail is exchanged in S/MIME formats [RFC5751] so as to take advantage of the deployed base of S/MIME clients.
The choice of S/MIME as the message format naturally leads to the use of X.509v3/PKIX as the certificate format but not necessarily according to the PKIX trust model.
When OpenPGP and PEM were being developed, few software libraries were available to support parsing and validation of X.509v3 certificates. Today these resources are commonplace and supported in virtually every major code development platform. Certificate generation tools, while somewhat less common are also freely available.
The following X.509v3 extension may be included in an end-entity certificate to describe the encrypted email security policy of the corresponding address.
[[Details TBD, the extension must allow the party identified to specify policies such as the following]
While the policy language could in principle include key pinning it is contrary to the PKIX architecture to incorporate information that constrains the use of one end-entity certificate in a different end-entity certificate.
One of the key weaknesses in the currently deployed S/MIME infrastructure is that most S/MIME clients rely on a Web browser to generate keys. This is unsatisfactory in many ways:
To address these shortcomings I propose that key generation and MUA configuration be the task of a new type of application, a key generation / MUA configuration tool supporting the following functions:
The functions of the key generation / MUA configuration tool could be integrated into an MUA but this is neither necessary nor necessarily desirable. Configuration of the user's security context should be an occasional event rather than one requiring frequent attention or even one that demands attention at regular intervals.
An MUA can assist the developers of such tools by publishing specifications that describe how to configure the application or by adopting standardized interfaces for exchange of the information (for example through the Windows registry or configuration files in well known locations on UNIX based machines).
While implementing the proposed features requires a new specification and new code, the work required is well understood and the design choices are limited to issues of syntax rather than substance. Accordingly, this portion of the testbed is considered to fall under the heading of execution rather than research. A detailed specification and sample code is in development.
In order to support Key Validation, some form of key endorsement infrastructure is required. The structure of endorsement infrastructure itself is research problem and MAY involve endorsement by specialist trust providers (i.e. Certificate Authorities), peer-to-peer endorsement by end entities (i.e. Web of Trust) and notarization (i.e. Certificate Transparency).
A standardized interface is required to separate the email client from the endorsement infrastructure. Such an interface MUST be capable of supporting existing key endorsement infrastructures (hence the need to generate a Certificate Signing Request) and MUST be capable of supporting the new infrastructures resulting from new research.
This interface is currently undefined. An additional JSON/REST based Web Service is required.
Key Discovery and Validation represent the research component of the email security problem. Previous experience suggests that rather than searching for 'the' solution to this problem we should seek out multiple solutions and ask which solutions are best suited for which purpose. The trust infrastructure that is suitable for protecting the confidentiality of communications between designers of network security protocols is not necessarily best suited for protecting the confidentiality and authenticity of email exchanges with a bank. It is even possible that different approaches to trust infrastructure may be best suited to different customers of the same bank.
To separate the research part of the problem from the execution part, the email client queries a Web Service each time an email message is sent to determine whether cryptographic enhancements should be applied and if so which ones.
The Omnibroker protocol is a JSON/REST style query protocol that is designed to answer questions of the form 'How should client X best connect to service Y'.
[TBD describe the exact means of applying Omnibroker to ask how to send an email to a recipient and answers that indicate use cases such as, send in plaintext, send encrypted under encryption Key X.]
Microsoft Outlook provides a mechanism for discovery of email contact data using a proprietary but documented protocol [MS-ASCNTC].
This might prove useful as a mechanism for supporting legacy clients that support S/MIME but do not provide an interface to a standards based certificate discovery mechanism. Though being based on the user's contact list, the mechanism only covers email sent to an address that is already in the contact list when the message is sent and synchronization of the contacts list may only take place on an infrequent basis with the result being cached rather than causing a fresh query to be made for each email message sent.
One option for using this feature would be to write a proxy to intercept interactions between the client and the Exchange server, adding entries for certificates that are found to be missing. A possibly better approach would be to scan the user's exchange contacts list on a regular basis and attempt to discover and add a certificate for each entry lacking one.
Making use of the testbed, whether for experimental or production purposes requires that it be integrated into some form of deployment vehicle. Three types of deployment vehicle are considered:
Native functionality is clearly preferred over the use of a plug-in or proxy but requires the most development effort. Native functionality offers the opportunity to extend the user interface to offer features such as the option to require encryption for specific messages, users or groups of users.
Many mail clients offer a plug-in capability that provides almost the same degree of flexibility as native code. But plug-ins are justifiably considered an unwelcome hazard in most Enterprise computing environments and increasingly so in consumer environments as well. However robust the design of the plug-in framework, the plug-in and host application must inevitably follow divergent development paths. Each update to the host application may affect the plug-in as may any other plug-in that is installed.
Writing a plug-in typically requires a detailed knowledge of the mail client and plug-in architecture that is only sometimes revealed in accessible documentation.
Use of a proxy service is probably the simplest deployment vehicle but is limited by the user interface functionality supported by the existing clients and the protocols by which the client interacts with the proxy.
Many email clients already support decryption of encrypted mail once the necessary decryption key is installed on the machine. It may be sufficient therefore to proxy the outbound email sent via SMTP/SUBMIT and perform opportunistic encryption if a corresponding encryption certificate can be found and the recipient prefers all email to be encrypted.
I am sure there are some.
Thanks to the many people who have encouraged me in this work and in particular the members of the IETF PERPASS list and the Cryptography mailing list. Future versions of the draft will have a more complete list.
| [RFC5055] | Freeman, T., Housley, R., Malpani, A., Cooper, D. and W. Polk, "Server_Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007. |
| [RFC2440] | Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. |
| [RFC1421] | Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. |