PSRG input to IMC meeting
Stephen Kent (kent@BBN.COM)
Tue, 20 Feb 1996 16:35:23 -0500
The Privacy and Security Research Group of the Internet Research Task Force
would like to provide some input to the Internet Mail Consortium's meeting
on secure electronic mail, which is being held in San Jose on February 21.
Because the PSRG is meeting concurrently this week in San Diego, our
members are unable to participate in your meeting, but hope the following
message will be a useful contribution to your deliberations.
Secure e-mail has been a long-awaited goal for many of us in the Internet
community, as well as a focus of activity for the PSRG and its membership
over the years. In this area, many of the PSRG members have participated in
the development of protocols and systems, so we applaud efforts to bring
together electronic mail developers and users to work toward common, usable
secure e-mail tools.
As a group, the PSRG has no particular preference for any one secure e-mail
protocol; however, we would like to suggest the following four (in
alphabetical order), based on our experience, as being the most suitable
for consideration by the IMC in developing common solutions:
-- MSP, the Message Security Protocol, developed for the U.S. Defense
Message System
-- MOSS, the MIME Object Security Services described in RFC 1848
-- PGP/MIME, the work in progress to integrate PGP into MIME
-- S/MIME, RSA Data Security cooperative effort to integrate its Public-Key
Cryptography Standard #7 into MIME
None of these systems is perfect, and each has relative strengths and
weaknesses. Nevertheless, each can contribute a significant amount of
design experience from which all can benefit, and we encourage an open
discussion of how secure e-mail ought to be designed, drawing from the
experience with each of these systems. Such a discussion, we hope, can
benefit the entire Internet community.
Having followed the ongoing e-mail discussion on this topic, the PSRG would
like to suggest that the IMC pay careful attention to the distinction
between secure e-mail protocols and implementations of these protocols.
While the availability of good implementations of secure e-mail protocols
is a valid evaluation factor (as noted below), it should not be confused
with the intrinsic features and limitations of the protocols per se.
The following is a brief list of some of the issues that the IMC might want
to consider during its discussion. The ordering of these issues is
arbitrary, i.e., it does not constitute a prioritization. We have divided
the list into protocol design issues vs. implementation issues, consistent
with belief that the two ought to be considered independently.
Protocol Design Issues
-- Algorithm independence. Although it is not always apparent, some
secure e-mail protocols rely on characteristics of specific cryptographic
algorithms, e.g., reliance on use of the same public-key algorithm for key
management and signature services. We believe a flexible design has
significant advantages, though implementation agreements are needed to
specify particular suites of algorithms.
-- Separation of security services. Clean separation between
confidentiality, authentication and integrity, and support for
non-repudiation services is beneficial. On the other hand, having too many
options for how services may be applied may be a hindrance to
interoperability and may also significantly complicate production of
compliant
implementations.
-- E-mail transfer formats. Secure e-mail protocol should include
provisions to make use of various e-mail transport systems, e.g., SMTP,
extended SMTP, maybe even X.400.
-- Content transfer formats. Secure e-mail protocols should accommodate
transport of various data types, e.g., binary, ASCII, non-ASCII character
sets, etc.
-- UA integration. Secure e-mail protocols should include provisions to
facilitate integration with UAs. It also might be designed to work
independently of UAs.
-- Availability of specifications. Protocol specifications should be
published to facilitate independent implementation. Copyright restrictions
should be minimal. One must weigh the relative merits of standards
developed in an open standards process vs. ones developed by industry or
government consortia.
-- Patent issues. One must evaluate the implications of protocols that
require the use of patented technology, either in terms of algorithms or
protocols.
-- Performance issues. Protocol specifications can influence the
performance of resulting implementations, both in terms of end-system
processing and in terms of transmission bandwidth overhead. Design
features that permit users (or system administrators) to minimize such
overhead may be important, e.g., selective inclusion of public-key
certificates in message headers.
-- Key management techniques and trust models. No single key management
scheme will be ideal for all user communities. For many communities,
scalability and support for digital signatures will be of prime importance
and use of public-key certificates will be a preferred method for providing
this support. An ability to distinguish between public keys used for
signature and public keys used for symmetric key management purposes also
may often be important.
Protocol Implementation Issues
We include the following list of implementation-specific issues that one
might use for evaluation purposes. We suggest that the IMC not select nor
reject any secure e-mail protocol on the basis of characteristics of
currently available implementations of that protocol. Nonetheless, it is
important that any recommended protocols not preclude, by virtue of their
design, good implementations relative to the following criteria.
-- Algorithm support: For an algorithm-independent protocol, what suites
of algorithms are supported by existing implementations of the system?
This will affect the generality and utility of the system.
-- CAPI use. Use of cryptographic application programming interface
support is an important feature of implementations as it facilitates
end-user selection of algorithm suites, choice of hardware or software
crypto, etc. As industry moves toward the standardization of such
interfaces, we believe it is important that secure e-mail systems make use
of them.
-- Availability of implementations. Implementations come in various
flavors, e.g., well-supported commercial implementations, freeware, and
source code. Various communities of users assign different weights to
different implementation options.
-- Human factors issues. It is important that users be able to interact
with secure e-mail systems in a fashion that makes it clear what security
services are being applied to what portions of a message, for both inbound
and outbound e-mail. For example, it is not attractive to provide good
encryption for a message that is sent to the wrong recipients because of a
poor key management interface.
-- Performance issues. Reasonable performance is critical to widespread
acceptance of a system and this is often very much a function of the
quality of an implementation of a specific protocol and the choice of
algorithms.
The relative importance of these issues will vary; we offer them primarily
as avenues for discussion. It might be helpful, for instance, to draw up a
chart summarizing the characteristics of each proposed secure e-mail
technology in each area of interest; this would enable easy comparison of
the systems, based on specific objectives, which may be different in one
environment than another.
For the record, the PSRG will be recommending to the Internet Engineering
Task Force that the specifications for Privacy-Enhanced Mail (RFCs
1421-24), which evolved from earlier work done by the PSRG, be moved
historical status. This is in recognition of the benefits of many of the
new systems based around MIME (PEM was oriented toward RFC 822 mail). The
experienced gained from the design and implementation of PEM, we hope, will
continue to impact work on the newer systems. Indeed, we expect RFC 1422,
which defines the public-key management techniques for PEM, to be
superseded as part of the IETF PKIX (public-key infrastructure) work. We
also expect RFC 1423, which defines algorithms, modes and identifiers for
PEM, and is also used by MOSS, to be updated to incorporate stronger
algorithms (e.g., triple DES and Fortezza cryptography).
Finally, as the steering group for the ISOC Symposium on Network and
Distributed
System Security, we hope to see many of attendees from the IMC meeting at
the SNDSS on Thursday and Friday, in San Diego.
Sincerely,
IRTF Privacy and Security Research Group
Steve Kent, BBN, Chair
David Balenson, TIS
Matt Bishop, UC Davis
Russ Housley, Spyrus
Burt Kaliski, RSA Laboratories
Dan Nessett, Sun Microsystems
Clifford Neuman, ISI
Rich Parker, NATO STC
Mike Roe, University of Cambridge