[apps-review] Review of: Certified Electronic Mail (draft-gennai-smime-cnipa-pec-07)
Dave CROCKER <dhc2@dcrocker.net> Sun, 08 August 2010 13:57 UTC
Return-Path: <dhc2@dcrocker.net>
X-Original-To: apps-review@core3.amsl.com
Delivered-To: apps-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319143A68C1; Sun, 8 Aug 2010 06:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.79
X-Spam-Level:
X-Spam-Status: No, score=-4.79 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_50=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsWsX6ehdQtQ; Sun, 8 Aug 2010 06:57:33 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 34AB03A6884; Sun, 8 Aug 2010 06:57:33 -0700 (PDT)
Received: from [192.168.1.102] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o78DvxnO027996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Aug 2010 06:58:04 -0700
Message-ID: <4C5EB7E1.2060406@dcrocker.net>
Date: Sun, 08 Aug 2010 06:57:53 -0700
From: Dave CROCKER <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: "apps-review@ietf.org" <apps-review@ietf.org>, draft-gennai-smime-cnipa-pec@tools.ietf.org
References: <4C594FD9.2050605@isode.com>
In-Reply-To: <4C594FD9.2050605@isode.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 08 Aug 2010 06:58:06 -0700 (PDT)
Cc: iesg <iesg@ietf.org>
Subject: [apps-review] Review of: Certified Electronic Mail (draft-gennai-smime-cnipa-pec-07)
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Apps Area Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Aug 2010 13:57:36 -0000
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