Internet Engineering Task Force (IETF) Phillip Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended Status: Standards Track October 27, 2014
Expires: April 30, 2015
PRISM-Proof Email Deployment Requirements
draft-hallambaker-prismproof-dep-01
Abstract
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.
Status of This Memo
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."
Copyright Notice
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.
April 30, 2015 [Page 1]
Internet-Draft PRISM-Proof Email Deployment October 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Earlier and Existing work . . . . . . . . . . . . . . . . 3
2. Requirements for Email Security . . . . . . . . . . . . . . . 5
2.1. Commercial Use . . . . . . . . . . . . . . . . . . . . . 6
2.2. Usability . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Availability . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Confidentiality and Access . . . . . . . . . . . . . . . 7
2.5. Integrity and Authenticity . . . . . . . . . . . . . . . 9
2.6. Key Publication, Discovery, and Identity . . . . . . . . 9
2.7. Administrative Privileges . . . . . . . . . . . . . . . . 10
3. Common Testbed . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Dividing the problem space between execution and research 11
3.2. Problem Simplification . . . . . . . . . . . . . . . . . 12
3.3. Transport . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Data Formats . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1. Email Security Policy Extensions . . . . . . . . . . 14
3.5. Key Generation and Disclosure . . . . . . . . . . . . . 15
3.5.1. Key and Endorsement Publication . . . . . . . . . . 16
3.6. Key Discovery and Validation . . . . . . . . . . . . . . 16
3.6.1. Omnibroker . . . . . . . . . . . . . . . . . . . . . 17
3.6.2. Exchange Contact Synchronization . . . . . . . . . . 17
4. Deployment Vehicles . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
April 30, 2015 [Page 2]
Internet-Draft PRISM-Proof Email Deployment October 2014
1. Introduction
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.
1.1. Earlier and Existing work
The IETF has attempted to produce an email security scheme on six
previous occasions:
Privacy Enhanced Mail (PEM) [~RFC1421]
PEM provided an email encryption and signature capability but
was not compatible with MIME message extensions that users
found to be more important and deployment of PEM depended on
establishing a PKI based on a trust model that is now
understood to be unfeasible.
S/MIME [!RFC5751]
S/MIME has achieved ubiquitous deployment in dedicated email
user agents but is not currently supported in Web Mail
products. Use of S/MIME requires a PKIX [!RFC5280] certificate
issued by a CA, a step that has proved too difficult for the
typical user and introduces a frequently criticized potential
point of failure.
April 30, 2015 [Page 3]
Internet-Draft PRISM-Proof Email Deployment October 2014
OpenPGP [~RFC2440]
OpenPGPhas achieved ubiquitous mindshare but almost no widely
used email user agent offers native support. OpenPGP supports
the same capabilities as S/MIME but uses a Web of Trust
approach to key validation which eliminates the need for CAs
but introduces scaling and usability limitations.
DKIM [!RFC6376]
DKIM provides only a means to authenticate a message to a
sending domain and does not offer the ability to authenticate
the user who sent the message or provide confidentiality
capabilities.
STARTTLS [!RFC3207]
STARTTLS is an SMTP extension that enables the use of Transport
Layer Security [!RFC5246]. While STARTTLS is supported by many
if not most modern mail servers, these deployments only provide
protection against a passive attack as the client does not
typically validate the credentials of the server receiving the
mail and the lack of a policy mechanism permits a man in the
middle to achieve a downgrade attack.
DANE [!RFC6698]
DANE provides a mechanism which is in principle capable of
being used to advise mail senders that a mail server offers the
STARTTLS extension and validating the certificate to be used
based on DNSSEC [!RFC4033].
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.
April 30, 2015 [Page 4]
Internet-Draft PRISM-Proof Email Deployment October 2014
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.
2. Requirements for Email Security
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.
April 30, 2015 [Page 5]
Internet-Draft PRISM-Proof Email Deployment October 2014
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.
2.1. Commercial Use
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.
2.2. Usability
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.
* Installing an configuring security should take no more effort
than configuring a mail application does today.
* Sending a mail message should require no more knowledge of the
recipient than their email address.
April 30, 2015 [Page 6]
Internet-Draft PRISM-Proof Email Deployment October 2014
* Mail should be secure by default, there should be no need to
click a button to sign or encrypt the message.
* A user MUST be able to force use of encryption when necessary
at the message, recipient and domain level.
* The MUA must provide the user with sufficient information to
perform their tasks securely and provide additional explanation
when necessary.
2.3. Availability
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.
[[Multiple-Devices]
Users must be able to access their secure mail from any of the
devices they currently read mail including mobile devices and
multiple desktop computers.
[[Archive]
Users must be certain that they will not lose access to their
email messages or archives.
[[Policy]
Users must be able to tell email senders which encrypted
formats they are capable of accepting and whether they prefer
email to be encrypted by default or not.
2.4. Confidentiality and Access
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.
* An enterprise needs access to all email messages sent to their
employees and contractors in their official capacity.
* An enterprise may be subject to regulations that require all
communications made in certain environments be recorded,
archived and made available for later inspection.
April 30, 2015 [Page 7]
Internet-Draft PRISM-Proof Email Deployment October 2014
* An enterprise may need to balance their need for
confidentiality against their other security objectives. In
particular efforts to block spam and malware.
* An email sender should know whether the message they are
sending is confidential to the identified individual or to the
domain name holder.
These concerns give rise to the following requirements:
[[Enterprise-Access]
A domain name holder must be able to control the use of
encryption enhancements in mail sent to their domain.
[[Sender-Notification]
An email sender must know whether the message they are sending
is confidential to the identified individual or to the domain
name holder.
Confidentiality is not a binary quality. An email sent by
alice@example.com to bob@example.net may be encrypted as follows:
* TLS security between Alice's MUA and the example.com outbound
mail server.
* TLS security between the example.com outbound mail server and
the example.net inbound server.
* TLS security between the example.net inbound server and Bob's
MUA.
* Message layer security under a public encryption key of
bob@example.net
* Message layer security under a public encryption key of
example.net
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,
April 30, 2015 [Page 8]
Internet-Draft PRISM-Proof Email Deployment October 2014
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.
2.5. Integrity and Authenticity
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.
2.6. Key Publication, Discovery, and Identity
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:
[[Publication]
Enable Alice, the authorized holder of example.com to generate
a public keypair and publish the public portion thereof for use
by email senders.
[[Discovery]
Map an email address (e.g. alice@example.com) to a certificate
purportedly belonging to the holder of account
alice@example.com.
[[Identity]
Establish whether the certificate purportedly belonging to
alice@example.com does in fact belong to the party the sender
intends.
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
April 30, 2015 [Page 9]
Internet-Draft PRISM-Proof Email Deployment October 2014
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:
[[Account-Identity]
The encryption key to use to encrypt email sent to
alice@example.com
[[Personal-Identity]
The encryption key to use to encrypt email sent to Alice
[[Organizational-Identity]
The encryption key to use to encrypt email sent to Alice
working at Example Inc, the owner of example.com.
2.7. Administrative Privileges
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
April 30, 2015 [Page 10]
Internet-Draft PRISM-Proof Email Deployment October 2014
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.
[[User-Autonomy]
It must be possible for Alice, the authorized holder of
alice@example.com to publish a public key for her account
without action by the domain administrator.
[[DNS-Control]
A DNS domain name owner must have the ability to control the
credentials issued for their domain should they choose to do
so.
3. Common Testbed
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.
3.1. Dividing the problem space between execution and research
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.
April 30, 2015 [Page 11]
Internet-Draft PRISM-Proof Email Deployment October 2014
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.
3.2. Problem Simplification
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:
* A user MUST be able to configure any email client so that they
can read encrypted email but the encryption provided MAY not be
end to end.
* A user MUST be able to send encrypted email from at least one
platform but MAY not be able to send encrypted email from every
platform.
* A user MUST be able to sent encrypted email to any party that
publishes a public key but MAY not be able to fully or even
partially validate the encryption key used.
April 30, 2015 [Page 12]
Internet-Draft PRISM-Proof Email Deployment October 2014
* No extensions to the email client user interface are required.
* The problem of email authentication is not addressed in the
testbed as improved authentication requires considerable
modification of the client user interface. For a comprehensive
description of the changes I believe to be necessary, see my
book The dotCrime Manifesto [!PHB2008].
* Discovery and validation of trust chains MAY be performed
partially or wholly in the cloud rather than end-to-end.
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.
3.3. Transport
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.
* SMTP, SUBMIT and IMAP traffic should always use TLS transport.
* Clients should support the use of a strong authentication
mechanism that does not disclose the authentication secret to
any party, including the purported service to which the client
is authenticating.
* Clients should be capable of validating the TLS Certificates
presented by the service.
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.
April 30, 2015 [Page 13]
Internet-Draft PRISM-Proof Email Deployment October 2014
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.
3.4. Data Formats
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.
3.4.1. Email Security Policy Extensions
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]
* Transport Security Policy: Required / Always offered /
Sometimes offered / Unknown
* Account Message Encryption Policy: Always / Sometimes / Never
* Domain Message Encryption Policy: Always / Sometimes / Never
* Message Signature Policy: Always / Sometimes / Never
* Domain Message Signature Policy: Always / Sometimes / Never
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.
April 30, 2015 [Page 14]
Internet-Draft PRISM-Proof Email Deployment October 2014
3.5. Key Generation and Disclosure
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:
* The process is not transparent. It is not clear to the user
that their public/private keypair is being generated by the Web
browser that they are using rather than by the CA that issues
the certificate.
* The key generation mechanism is potentially vulnerable to
weaknesses in the random number generation routine used and may
even be compromised by a covert channel attack (kleptography).
* Only the PKIX trust model is supported.
* The certificate will only be published to a directory if the CA
performs the operation.
* The user is left to configure their MUA(s) themselves, a
process that frequently requires them to interact with a user
interface that is frequently illogical and obscure.
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:
* Allows the user/domain to specify their email encryption policy
(always, sometimes, never)
* Generates public/private key pairs [[Stretch] Generate private
keys in a format that precludes/minimizes covert channel.
Supports use of an archival service with appropriate safeguards
to protect confidentiality of the private key (e.g. key
shares).
* Recovers a private key from archival format
* Registers the public key with disclosure service: Generate a
Certificate Signing Request (CSR) [!RFC2986]. Generate a Self-
Signed certificate
* Configures a MUAs installed on the machine to make use of the
private keypair in accordance with the specified policy.
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
April 30, 2015 [Page 15]
Internet-Draft PRISM-Proof Email Deployment October 2014
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.
3.5.1. Key and Endorsement Publication
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.
3.6. Key Discovery and Validation
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.
April 30, 2015 [Page 16]
Internet-Draft PRISM-Proof Email Deployment October 2014
3.6.1. Omnibroker
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.]
3.6.2. Exchange Contact Synchronization
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.
4. Deployment Vehicles
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 in a mail client
* A mail client plug-in
* A proxy service.
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.
April 30, 2015 [Page 17]
Internet-Draft PRISM-Proof Email Deployment October 2014
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.
5. Security Considerations
I am sure there are some.
6. Acknowledgments
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.
7. References
7.1. Normative References
[PHB2008] Hallam_Baker, P, "The dotCrime Manifesto: How to Stop
Internet Crime", Semptember 2013.
[I-D.hallambaker-omnibroker] Hallam-Baker, P, "OmniBroker Protocol",
Internet-Draft draft-hallambaker-omnibroker-06, 8 July
2013.
[I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect
(JCX) Protocol", Internet-Draft draft-hallambaker-
wsconnect-04, 8 July 2013.
April 30, 2015 [Page 18]
Internet-Draft PRISM-Proof Email Deployment October 2014
[MS-ASCNTC] , "[Reference Not Found!]".
[RFC2986] ,Nystrom, M.,Kaliski, B., "PKCS #10: Certification Request
Syntax Specification Version 1.7", RFC 2986, November
2000.
[I-D.evans-palmer-key-pinning] Evans, C,Palmer, C, "Public Key
Pinning Extension for HTTP", Internet-Draft draft-evans-
palmer-key-pinning-00, 14 November 2011.
[RFC4033] Arends, R.,Austein, R.,Larson, M.,Massey, D.,Rose, S.,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[RFC6376] Crocker, D.,Hansen, T.,Kucherawy, M., "DomainKeys
Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
September 2011.
[RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley,
R.,Polk, W., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 5280, May 2008.
[RFC5751] Ramsdell, B.,Turner, S., "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC6698] Hoffman, P.,Schlyter, J., "The DNS_Based Authentication of
Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
[RFC5246] Dierks, T.,Rescorla, E., "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
7.2. Informative References
[RFC5055] Freeman, T.,Housley, R.,Malpani, A.,Cooper, D.,Polk, W.,
"Server_Based Certificate Validation Protocol (SCVP)", RFC
5055, December 2007.
[RFC2440] Callas, J.,Donnerhacke, L.,Finney, H.,Thayer, R., "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.
April 30, 2015 [Page 19]
Internet-Draft PRISM-Proof Email Deployment October 2014
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
philliph@comodo.com
April 30, 2015 [Page 20]