A brief comparison of email encryption protocols

Thu Feb 15 00:45:58 PST 1996

   This message briefly reviews and compares the four major email
encryption protocols under discussion: MOSS, PGP, PGP/MIME, and
S/MIME. Each is capable of adequate security, but also suffers from
the lack of good implementation, in the context of transparent email
encryption.

   I will try to address issues of underlying cryptographic soundness,
ease of integration with email, implementation issues, support for
multimedia and Web datatypes, and backwards compatibility.

   An additional grave concern is key management. Contrary to some
beliefs, key management is not a solved problem. All of the proposals
contain some mechanism for key management, but none of them have been
demonstrated to be scalable to an Internet-wide email system. My
belief is that the problems with key management do not stem from the
classic Web of trust/certification hierarchy split, but the
nonexistence of a distributed database (with nice interfaces) for
holding keys. The encryption protocols also stand in the way of such a
database, with key formats that are either overly complex, inadequate,
or both.

   In case it is not clear by now, this review will be quite
subjective, in many cases representing my own beliefs rather than
objective fact. I'll try to point that out where I can. Also, I do not
claim to have a thorough understanding of PEM and PKCS. Much of my
knowledge comes from implementing premail, a tool that acts as "glue"
between mailers and encryption packages. It supports PGP, MOSS (using
the TIS/MOSS 7.1 implementation), and a draft of PGP/MIME, in addition
to a wide range of anonymous remailer services. While usable, premail
has many limitations, and certainly does not represent the "holy
grail" of transparent email/crypto integration. Thus, my participation
in the Internet Mail Consortium Secuirty Workshop
(http://www.imc.org/security-workshop.html).

   I apologize for the wide distribution, and ask that followups be
trimmed.

PGP
---

   PGP (Pretty Good Privacy) is, of course, the de facto standard for
email encryption on the Internet.
   PGP's underlying cryptography is quite sound - RSA (up to 2048 bits
with the most recent implementation), IDEA with a 128 bit key, and
MD5. PGP is entirely in accordance with the recent recommendations on
minimum keylength (http://www.bsa.org/bsa/cryptologists.html), and in
fact does not include a mode of operation in violation of those
recommendations. This makes PGP (and, by extension, PGP/MIME) unique
among the encryption protocols.
   PGP is packaged in a single application (i.e. a single binary)
which performs encryption, decryption, signing, verification, and key
management. It does not depend on the existence of great deal of
infrastructure. These factors have, in my opinion, been decisive in
PGP's popularity.

   However, PGP is still not suitable for fully transparent email
encryption. The reasons are complex, and I will only touch on them
here.

   The main missing feature is the lack of MIME integration. Thus, PGP
is not suitable for multimedia types other than US-ASCII text. PGP
does contain some support for 8-bit charsets, but at cross-purposes
with MIME. Signature checking of non-US-ASCII data is simply not
reliable. To give an idea of this problem, the most recent
international version (2.6.3i) tries several different character set
conversions when verifying signatures, to see if any of them will
work.
   However, since a large fraction of email _is_ US-ASCII text, this
feature alone probably does not explain the lack of deployment. PGP
contains a number of implementation flaws (including silly things like
not locking files, so that concurrent invocations fail). In addition,
key management has some problems. Mostly, key management is hard to
learn, time consuming, and requires a great deal of manual
intervention. The "Web of trust" is supposed to fix this, by providing
transitive trust of key authenticity. However, in practice the Web of
trust has not delivered. In my experience (with many dozen
correspondents), I have only had one or two keys transitively trusted.

   A standard PGP-signed message consists of a "-----BEGIN PGP SIGNED
MESSAGE-----" line, the signed text (subject to some canonicalization
rules), a "----BEGIN PGP SIGNATURE-----" line, a version line, the PGP
signature itself, and an "-----END PGP SIGNATURE-----" line. All this
is in the message body. The headers indicate that the message is a
standard 7-bit, us-ascii, text/plain message. Thus, mailers have to
parse the message contents to identify the message as PGP signed, or
to extract the signed parts. This is at cross-purposes with MIME.
Mailer implementors are reluctant to include such ad-hoc extensions.
Existing extensibility mechanisms, based on MIME, cannot be used.
   PGP encrypted messages are similar - the identification as an
encrypted message can only be made by parsing the message body.

   One technical problem with PGP is its inability to support
single-pass processing, because the data format includes a size
field.

PGP/MIME
--------

   PGP/MIME is an effort to integrate MIME and PGP. There is a
workable draft based on the MIME security multiparts, but the PGP/MIME
mailing list is divided. Some particpants are happy with the existing
draft, while others feel that other points in the design space
(for the most part, labelling existing PGP message formats with
appropriate MIME types) would be better.
   The design space is large and complex, with many constraints on
efficiency, simplicity, backwards compatibility, and functionality. It
is not clear that a consensus will develop at all.
   There are two implementations of the PGP/MIME draft: premail, and
the PGPMIME reference implementation by Michael Elkins.
   For more information about the PGP/MIME draft, see
http://www.c2.org/~raph/pgpmime.html .

PGP 3.0
-------

   Many people are hoping that PGP 3.0 will somehow come along and
solve all their problems. PGP 3.0 is only an evolutionary improvement
over the existing implementations (MIT PGP 2.6.2 and PGP 2.6.3i). For
the most part, it will support only the existing message formats.
There may be support for decoding draft PGP/MIME signed messages, but
this is still being negotiated.
   The main advance in PGP 3.0 is a cleaned up implemenation. The PGP
2.6.2 code is disgusting, and should not be integrated directly into
any mailer application. The 3.0 code will be modular and based on
published interfaces. Furthermore, the 3.0 development team plans to
release the code as both a stand-alone application and as a library.
   It is difficult to predict when the public release will happen.
Based on what I've seen, fall of 1996 seems the most likely.

MOSS
----

   MOSS (MIME Object Security Services) is an attempt at an email
encryption protocol in accordance with MIME. It is currently an
Internet RFC. There is a reference implementation (TIS/MOSS 7.1).
   MOSS is mostly cryptographically sound. However, the choice of
symmetric encryption algorithm (and key size) is left unspecified.
Thus, it cannot be said that MOSS is in accordance with the
recommendations for minimum keysize. In fact, the only public
implementation, TIS/MOSS 7.1, uses 56-bit DES, which is in direct
violation of these standards.
   The TIS/MOSS implementation has a number of other problems. It is
big and complex, probably due to its TIS/PEM ancestry. For more
information about TIS/MOSS, see
http://www.tis.com/docs/Products/tismoss.html .

   MOSS supports two modes of key management: X.509, and completely
manual key management. In this way, it is a dramatic advance over PEM,
which only supported X.509, but life for implementors remains hard.
One feature which I believe is sorely lacking is a cryptographic hash
of the public key as the basic unit of manual key management. Thus,
people either have to trust the mechanism by which the key was
delivered, or examine the base-64 representation of the entire key. I
consider this to be a serious usability problem.
   For an example of how hashes of keys have been done right, see
Netscape 2.0's handling of untrusted certificates.

S/MIME
------

   S/MIME is an attempt to graft MIME support onto underlying PEM
standards. See http://www.rsa.com/rsa/S-MIME/ for more info.

   I feel compelled to deal harshly with RSA's S/MIME FAQ
(http://www.rsa.com/rsa/S-MIME/smimeqa.htm). It suggests that MOSS has
interoperability problems because of multiple implementations, while
S/MIME presumably doesn't. I take strong exception to this statement.
There is no technical basis for it. I consider the possibility of
admitting multiple implementations as a _requirement_ for an Internet
email standard. However, because S/MIME is documented, it hopefully
will be possible to create independent implementations, in spite of
what RSA says.

   The only symmetric encryption algorithm mandated by S/MIME is
40-bit RC2. Thus, S/MIME is in violation of the key size
recommendations. Further, RC2 has not been confirmed to be publicly
known. If RC2 is not known, then an independent implementation of
S/MIME is impossible. Fortunately, source code for an alleged
implementation of RC2 has recently been posted to the Internet,
resolving this problem, if it is authentic. If not, then my
reservations remain.

   S/MIME also recommends 56-bit DES CBC and (either 112 or 168 bit)
DES EDE3-CBC. This is good; any S/MIME implementation in accordance
with the recommendations will conform to the keysize recommendations
as well.

   S/MIME remains firmly grounded in the X.509 certification
hierarchy, although the FAQ claims that the guidelines for hierarchies
are "more flexible" than in PEM.

   One cryptographic weakness of S/MIME is that eavesdroppers can
distinguish between encrypted and signed-and-encrypted messages. This
violates the principle of disclosing a minimum amount of information.
PGP, PGP/MIME, and MOSS do not have this problem.

   Probably the most controversial aspect of S/MIME is its signature
format. An S/MIME signed message is a MIME multipart in which the
first part is the data to be signed, and the second part is a complete
PKCS #7 (section 10) signed message. This protects quite well against
munging by mail transport, but has two problems. First, the size of
the message is doubled. Second, the fact that the two singed messages
are identical is not enforced (if it were, mailer munging would cause
too many signatures to fail). Thus, Eve can send Alice and Bob a
message (M1, (M2, Signature(M2))). Alice, not having an S/MIME
implementation, would see only M1. Bob, having an S/MIME
implementation, would see only M2, for which the signature would
check. Alice, being suspicious, might call Bob up on the telephone and
ask whether the signature was really valid. Bob would of course say
yes. Unless they compared notes on the contents, they would not notice
the discrepancy. To my mind, this counts as protocol failure, and thus
it is not possible to claim that S/MIME conforms to best cryptographic
practice.
   I would expect that doubling the message body will create
performance problems in a Web environment. For example, if the first
message is used for display, then it becomes necessary to compare the
two messages. If, instead, the second message is used, then the first
message will be responsible for significant added latency.

Integration with mailers
------------------------

   Integration with mailers is quite difficult. In general, the mailer
implementor will need to add specific features to support
cryptography. Because of the restrictiveness of ITAR regulations, such
an approach may not be practical for US developers, at least while
supporting strong cryptography.
   Perhaps the biggest feature required in the mailer is integration
of key management and the "address book". If this feature is not
implemented in the mailer, then two address books are required - one
to select email addresses, and another to map email addresses to keys.
This approach is used by premail, and is the source of many usability
problems. It would be nice if a database existed which could map email
addresses to public keys without manual intervention, but none of the
proposals on the table are capable of it. Such a database would
certainly improve usability, as well as making it considerably easier
to 

   Another feature that is required for fully transparent integration
is caching of decrypted session keys. If not implemented, then the
user interface delays in navigating a mail folder become unacceptable.
To my knowledge, no implementation supports this feature.
   One dimension in the design space is whether the cryptographic
engine is tightly integrated with the mailer (i.e. shares an address
space), or is a separate process that communicates with the mailer.
Both approaches have been implemented. Both approaches are subject to
numerous pitfalls, which have unfortunately not been entirely avoided.
   These issues have more to do with implementation than with the
encryption protocol, but I thought I'd mention them here, so that they
are not actively thwarted.

Conclusion
----------

   All of the proposals described here can be used for secure email.
None of them will be widely deployed in this capacity unless they are
implemented well. I have concerns that both MOSS and S/MIME are
susceptible to political pressure which will restrict key sizes
insecurely in practice. I would like to see consensus develop around
one of the proposals, so that energies used for implementation can be
more focussed and effective. It is my hope that this conference will
move in that direction.

Raph Levien