Review of:

    Certified Electronic Mail

    Gennai, Shahin, Petrucci, Vinciarelli
    draft-gennai-smime-cnipa-pec-08


Reviewed by:

    D. Crocker
    dcrocker@bbiw.net
    8 August 2010



This is a summary review, with a focus on design goals and systems-level issues.
Based on my reading of the specification, much more in-depth reviews of this
specification are appropriate and required, to consider the fine-grained details
which could be problematic.  However, this deeper review should wait for
resolution of the more basic problems with the design and specification.



The specification is for security-related enhancements to Internet Mail[1], for
a service using the acronym PEC.  The covered security functions are:
"...sender identity, message integrity, confidentiality, and non-repudiation of
origin."  Each of these is a well-understood technical capability, in terms of
underlying algorithms.  The challenges, then, are in clarity about:

      1) The "social" purposes for using these features.

      2) The overall systems design for scalable and efficient operations, and
         use.

      3) The differences from prior work that make success more likely for the
         current service than has been achieved by those earlier efforts.

Different usage intent can make the provided features more or less appropriate.
In particular, identity and repudiation are security-related functions that are
significantly sensitive to usage confusion and varying goals.

The specification does not indicate the uses for which this service is
appropriate and those for which it is not.  For example, there is a considerable
difference in the technical demands for a service ensuring that a personal
message is really from a friend, versus a company's honoring a contract based on
certification of the contract's authorship, versus treating a government
directive as duly authorized.

      The specification must indicate and justify the boundaries of its use.

"Sender identity" and "non-repudiation of origin" are particularly challenging
services to understand and provide in complex and open environments.  Even the
meaning of "sender identity" is subject to some choice, depending upon the
particular uses of what is being validated.  The specification does not define
its meaning -- it does not even define identity -- although the identity is
certified through a strict x.509 model as applied to the address identifier in
an email's author From: header field.  Presumably this is to assert a formal
association between this online identifier and some sort of nationally-certified
identity.

      The specification needs to define the identifier to be used, its
      association with an identity, and the justification for these choices.
      This will permit and constrain possible usage scenarios for this service.

Of the listed component services, non-repudiation is the one technical
capability that has a particularly limited history of deployment.  It's most
simple implementation is through a trusted and accountable transmission service,
as provided for decades by EDI Value-Added Networks[13]. This is a form of
"channel" security, with the carriage service doing the vouching.
Transport-independent object-oriented non-repudiation is accomplished with
cryptographic tools that wrap information around a message.  For this the core
requirement is an external, trusted time-stamping service based on the relevant
identifier and a hash of the relevant content.  The triple of [actor
identifier, content hash, and timestamp] provide a basis for later proof of
authorship. Although often provided as part of message relaying, this can be
implemented by an external agent service that is merely provided the identifier
and hash, but does not directly touch the actual message.  (For example, this is
the basis of the Goodmail[10] design.)

Typical, paper-based postal certified mail provides non-repudiation of origin,
but not of author.  That is, it validates information about the place of origin,
but does nothing to certify the identity of the purported author.  The current
specification appears to assert non-repudiation of authorship.  Typical postal
certification can include non-repudiation of receipt.  The current service does
not provide that.

For Internet Mail, each of the target functions has twenty years of Internet
history, at least dating back to Privacy Enhanced Mail[2] and more recently with
OpenPGP[14] and S/MIME[3]. More generally, efforts for public services of these
types date back at least thirty years, notably with X.400[7].  In each case,
they have at best achieved very modest success, and even then only within
carefully controlled or constrained environments.

To limit the level of expertise required by end users, the specification cites a
distinctive design goal of using "...applications running on servers to
digitally sign messages, thus avoiding the complexity end-to-end systems bring
about."  However the specification indicates that signatures are to be verified
in email clients.  This is an example of the goal and design confusion in the
specification.

      From the specification, it is not clear where work is performed within the
      service architecture, or why.  This is indicative of the more general lack
      of a complete architectural description.

      A detailed listing and review of the design's assumptions and conflicts
      needs to be made and documented, with particular attention to operations
      and end-user usability. Their efficacy also needs to be considered in a
      substantive, documented manner, beyond simple guessing. Usability is an
      empirical design specialty.

The design is built upon a base of existing Internet Mail format and exchange
protocols, as well as S/MIME[3] for security-oriented message encoding, TLS[4]
for internal channel security, X.509[5] for trust-based certificates and LDAP[6]
for database queries.  In every case of using these technologies, the
specification defines constraints, enhancements or usage profiles to them.

      The specification does not make clear when it is modifying or enhancing or
      profiling an underlying component technology or service.  It needs to be
      explicit about labeling the places and ways in which it is doing this.

      Equally, the specification needs to make clear what modifications are
      required for existing email functionality, such as to MUAs, MSAs, MTAs and
      MDAs.  This is essential for assessing the adoption and incremental
      operations effort.

The specification uses the terms "message" and "envelope" in a confusing manner.
Message refers both to an electronic mail message and to a "PEC" system control
message.  Envelope is a reserved term in email but is also used in the
specification to refer to a PEC "transport" control message, apparently as
distinct from other types of PEC control messages. The term "transport" might
also engender confusion, given its industry use to refer various to TCP and SMTP.

      In general, the vocabulary chosen for the specification is confusing and
      needs to be modified and clarified.

The system description is based on Section 2.2 "Basic Structure".  The sole
diagram in the specification shows users at either end, with sending and
receiving certified electronic mail (PEC) providers depicted in between.

      The specification does not discuss the security and trust requirements
      that must be in satisfied by PEC providers. This is a critical omission
      from the specification and must be rectified.

A sending provider is shown as having an:

   a) Access Point, for interaction with the user.  Apparently this is for a
posting sequence, per the MUA-MSA interaction per [1]; if so, the connection is
unidirectional.

   b) Incoming Point, for interaction between PEC providers; for typical
message flows, this is unidirectional.

   c) Delivery Point, which "forwards [messages] to the final recipient"; this
appears to make no distinction between relaying from one provider to another,
versus the typical meaning of email delivery, which is from a provider to a
recipient's mailbox.

The receiving provider does not have the Access Point.

The relationship between an an Access Point and an Incoming Point is not
described.  Neither is the relationship between Incoming Point and a Delivery
Point. Given that these latter two apparently both conduct external interactions
"towards" the recipient, the definitions of these two functions appear to be in
conflict.

      The specification needs to clarify the relationships between an Access
      Point and an Incoming point, and between an Incoming Point and a Delivery
      Point.

Within a PEC provider box the diagram is generic, in that the relationships
among the depicted functions of a provider are not indicated.  The diagram shows
bidirectional exchanges taking place between the a user and their provider and
between PEC providers. The diagram does not indicate the types of interactions
taking place between a user and a provider.

There is no depiction of the overall flow for actual email, unless that is meant
to be implied within the one diagram in the document.  Even then, the fact that
all connections are shown as bi-directional means that sequential "flow" is not
indicated at all.  It appears that bi-directionality of the links is meant to
indicate the chatter of underlying request/response protocol conversations.

      It would be far more helpful to have the diagram indicate overall
      information flow, to achieve an end-to-end posting and delivery sequence.
      No other diagrams are present in the specification, and particularly none
      showing such flow(s).  This is a critical omission from the specification.

The specification mandates that an email message have the same Sender: header
field address as the From: field.  No rationale is provided, nor is there
discussion of the significant restriction this imposes on email behaviors that
otherwise would be legitimate.

      Given sufficient rationale and specification of appropriate usage
      scenarios, this constraint might be warranted.  Given the current
      documentation it seems merely arbitrary.  The specification, or a companion
      document, must justify the choices.

The specification mandates having the X.509 certificate's identifier match the
address in the From: header field. This is asserted to be necessary for
verifying the signature, but that assertion is not obviously correct and is more
probably incorrect.  More likely is the belief that this validates an assertion
of authorship.

      As a semantic enhancement to email, it can be reasonable to assert that a
      match between a X.509 identifier and the verified From: field address of a
      message validates authorship. However this enhancement needs to be
      specified explicitly and thoroughly.

The specification calls for modifying a From: header field to eliminate the
author-supplied "display" name, replacing it with the original author email
address and a prefatory string "On behalf of", using a PEC address in the From:
header field's email address.  These changes are claimed to improve message
usability.  The meaning of usability, in this case, is not provided.

      In terms of user interface design, the premise of the change to the From:
      header field is empirically invalid. In fact for typical recipients their
      understanding of message authorship will be greatly reduced.


Comments:

      The many efforts to deploy this type of functionality -- including recent
commercial efforts such as PostX[9], Tumbleweed[8] and Goodmail[10] -- have all
achieved no better than modest success and arguably not even that.  Utility in
large scale, for a broad market, remains elusive.  There appear to be several
core barriers to adoption, operation and use.  The current proposal does not
clearly and directly address any of them.

      The authors need to document a careful review of prior work and explain
what is different in the current work, as well as the theoretical and empirical
bases for believing that these differences will make success more likely for the
current work.

      The first priority for this specification is to properly document its
architecture, probably in a separate document.  This requires clear and complete
diagrams and data flow, and carefully selected vocabulary.

      For example, the design apparently intends to offload some security
functions to external servers, rather than perform them in their usually venue
of the MUA.  This is cited as improving usability; however the details and
rationale for this are not clearly supplied.  (For reference, note that
offloading was attempted for organization-to-organization security during
initial testing of PEM, by Trusted Information Systems.  Another variant is
typically performed for DKIM[11] with server-to-server authentication, albeit
for much more modest security functions.)

      It is widely -- and I believe correctly -- held that the primary barriers
to success for this class of service are matters of operational and end-user
usability.  Problems with security-related usability design, systems
administration, user interface design, user cognitive models for computer,
network and email security, suffer a very poor state of the art, and remain open
research topics.  There is an extremely poor record for mass-market security
products and only a slightly better record in research.  For example see SOUPS[12].

      While government mandate can force products to be produced, it cannot
guarantee usability.  The primary effect of government mandate about poor
technology service design is expenditure for products that are not used that
remain limited to very constrained environments.  (X.400 and OSI in general
supplied a powerful demonstration of this fact.)

      The goals of the specification appear to be reasonable and even laudable.
Unfortunately, the likely success of this design is not promising.


d/
--------


[1] Internet Mail Architecture, <http://tools.ietf.org/html/rfc5598>

[2] Privacy Enhanced Mail,
<http://en.wikipedia.org/wiki/Privacy-enhanced_Electronic_Mail>

[3] S/MIME, <http://en.wikipedia.org/wiki/S/MIME>

[4] TLS, <http://en.wikipedia.org/wiki/Transport_Layer_Security>

[5] X.509, <http://en.wikipedia.org/wiki/X.509>

[6] LDAP, <http://en.wikipedia.org/wiki/LDAP>

[7] X.400, <http://en.wikipedia.org/wiki/X.400>

[8] Tumbleweed,
<http://www.axway.com/products-solutions/email-identity-security/comprehensive-email-security>

[9] PostX,m
<http://www.anidirect.com/assets/files/encryption/ironport_encryption_overview.pdf>

[10] Goodmail, <http://www.goodmailsystems.com/>

[11] DKIM, <http://dkim.org>

[12] SOUPS, <http://cups.cs.cmu.edu/soups/2010/>

[13] EDI VAN, <http://en.wikipedia.org/wiki/Value_added_network>

[14] OpenPGP, <http://www.openpgp.org>

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net