Senders must be able to reliably verify that recipients have indeed received and read their correspondence. Far too often nowadays, senders are confronted with the need to contact recipients using conventional telephone in order to verify that they indeed received critical email, thereby largely defeating the benefits of using email. While there are a variety of reasons why email may fail to reach a recipient, including the ever more zealous spam filters used to protect corporate networks, the provided mechanism must allow the sender to identify lack of receipt without having to rely on additional communication mechanisms.

In addition, tracking functionality should not require recipients to access email through a website, either hosted by a third party or by the sender's organization. Instead, recipients must be able to receive, process and read email requiring Proof-of-Delivery (PoD) within the email client application which they commonly use on a day-to-day basis. We believe that redirecting recipients to websites for secure delivery of email is a fundamental, and ultimately dangerous, security flaw that can easily be exploited by malicious parties. There is, in fact, nothing precluding attackers from replicating the visual aspects of any website, no matter how customized or branded it may be, in order to impersonate you vis-a-vis your recipients -- a technique commonly known as "phishing." By teaching your recipients to depend on such delivery mechanism, you would, in fact, be putting them at risk of divulging important private information to ill-intentioned third parties. Put simply, the use of such websites provides a false sense of security.

Also, contrary to the optional proof of receipt functionality found in some email applications, a secure tracking mechanism should not allow the recipient to read email requiring PoD unless explicit agreement is provided to the effect that the sender be informed of the receipt. In addition, such mechanism should not be enforced using application-level security (more on this topic below.) Rather, enforcement should be at the protocol level and, therefore, even if the recipient were to bypass or hack the software components required to deal with the PoD, the underlying protocol would still require him to acknowledge receipt in order to be able to read the received email. Hence, the sender obtains irrefutable proof that the recipient has indeed received and read the email.

Finally, tracking should not be implemented by way of taking advantage of the behavior of some email client applications with regards to the content of the emails they receive. Such functionality which is claimed to allow senders to monitor the amount of time their recipients spend reading their email, for example, often suffers from inherent technical limitations, such as not being applicable to any sort of text email but only HTML emails, and actually relies on mechanisms which would likely be considered immoral should those receiving such email understood how those mechanisms were used to spy on their handling of incoming email.

Senders must be able to transmit sensitive information, be it in the email body or as attachments, to their recipients without requiring the later to having deployed any sort of email security product, public keys or certificate infrastructure. This is a crucial departure from traditional email security technologies which required recipients to create, publish and manage cryptographic identities in order to receive any form of encrypted content. We believe that this requirement was one of the fundamental design flaws that has led to the failure of classic email security systems to reach any sort of mass adoption. From a user experience standpoint, it is, in fact, much more intuitive if the onus is on the sender, and not the recipient, to secure email transmission.

Therefore, an effective encryption functionality must entirely rely on the sender's deployment of the appropriate infrastructure, while requiring as little effort or involvement on the part of the recipient to read secured email. Such an approach should still avoid the pitfalls of oversimplification and, therefore, not go as far as requiring no effort whatsoever on the part of the recipient, say by inviting him to read secured email by sending him a link to a website for retrieving actual content instead of a self-contained email. While we do understand that some recipients may resist having to participate in any security effort, say by having to install a plugin for example, we do not believe that there exists any other realistic solution -- save for systems which, as we explained earlier, lead to a false sense of security and are, therefore, even worse than no security at all.

There will always be, of course, recipients who are more proactive in securing their email transmissions and any encryption mechanism should take advantage of any such commitment. So therefore, an effective encryption mechanism should automatically distinguish between recipients having already deployed the mechanism and those who haven't. When communicating with recipients who have deployed the mechanism, no special procedure should be required on the part of senders. On the other hand, when communicating with recipients who haven't deployed the mechanism, senders should be required to effect the least amount of effort necessary, say by attributing a password for such recipients and communicating said password to the designated recipient at least once using other means than email. The password should preferably of course be made to be automatically reused for future correspondence with the same recipient.

Also, senders communicating with recipients not having already deployed the mechanism should be given the option of allowing said recipients to respond to their email in a secure fashion. Again, this should not be through some website, but rather directly within the recipient's existing email client application framework. Such an option should be available on demand to the sender for each transmitted email and expire once it has been used by the recipient. Hence, this allows for back-and-forth secure communication in between an initiating sender and a recipient not having deployed the mechanism.

Furthermore, the sender should not have to be mislead with regards to the level of control that he possesses over email that he has sent and that has been successfully decrypted by an authorized recipient. Specifically, contrary to what some products on the market claim, once a recipient has the ability to read an email, there are a great deal many ways in which he can thereafter capture and forward such correspondence to 3rd parties. There is, therefore, absolutely no restriction mechanism which can be effectively used to control a recipient's true handling of a decrypted email. This is, in fact, exactly the same limitation found in more traditional paper correspondence in that a sender has no control over a recipient's photocopying and further retransmission of confidential documents. If indeed senders must absolutely maintain control over a given document then, as in the paper world, we would invite such senders to refrain from transmitting the sensitive document and, instead, arrange for the designated recipient party to read a hardcopy in person.

Senders should be able to mark their emails so that recipients may reliably authenticate an email's origin. In fact, an effective email sender authentication mechanism must be the cornerstone of any email security infrastructure. Granted that, on a day by day basis, users don't look at authentication as a feature in and of itself. Nevertheless, without a truly effective authentication mechanism, any other functionality, including tracking and encryption, becomes easily exploitable by malicious third parties. The selection of any email security infrastructure should therefore be strongly gated by the real-world usability and inherent effectiveness of its authentication mechanism.

Firstly, email sender verification should be available to actual end user recipients. While a number of authentication mechanisms have been put forth to allow network equipment and mail servers to verify an email's origin based on network properties, such as IP addresses and DNS entries, these mechanisms are very limited in scope. They cannot, in fact, be used by common users to verify the origin of email they received with secure content. Even if such mechanisms could be used by end users, they would only allow them to check for the status of network properties which are of no direct value to a user. Instead, an effective authentication mechanism should allow the recipient user to verify information which he can readily relate to, such as the authenticated legal name of the sender's organization.

Secondly, email sender verification should not require the recipient to manually import any sort of cryptographic identity or rely on long-lived certificates minted by third parties. Instead, identity verification should be performed transparently for the recipient. Any up-to-date requests for identity keys or the likes must be conducted automatically at receipt of the email by the appropriate software and a status should be displayed to the recipient with regards to the validity of the signature accompanying the email, if any.

Thirdly, the verification process should be capable of verifying the validity of separate email parts independently from one another. For example, if the subject line has changed in transit while the body hasn't then the authentication mechanism should be able to report that fact to the user. Many existing authentication mechanisms are unable to validate emails at such a granularity and are therefore of very limited use given that email parts may variably change depending on an email's transmission path. Emails going through certain types of mail servers, for example, often have changing "from" fields. Likewise, emails posted to mailing lists often have changing subject lines and bodies. Only an authentication mechanism capable of separately validating email parts independently can have a reasonable chance of being adaptable to the various email delivery setups commonly found on the Internet.

Moreover, the initial process by which entities are vetted and considered to be identified must not either be trivial to undertake or be narrow in its scope. As such, candidate organizations should have their legal existence checked with multiple complementary sources, and there should be a demonstrable record that they are indeed reputable and trustworthy parties. Without such a process, an authentication mechanism does not provide any tangible guarantees to recipients.

Furthermore, once entities are accredited as conforming to a set of requirements, there must be an effective and reliable mechanism for ensuring continuous adherence to specific rules of conduct. Unlike current common practice with some technologies, for example, there should be no blanket certification without the possibility of early revocation. Instead, technical means should be available to rapidly identify and contain abusing parties, and responsible business policies should be in place for enforcing adherence to outlined rules regardless of potential short-term revenue losses to the organization responsible for such an authentication mechanism.

Finally, in addition to allowing end recipients to validate an email's originating organization or individual, the authentication mechanism must also allow end recipients to obtain guarantees with regards to the content of the incoming email. As such, it is highly desirable that any authentication mechanism prohibit senders from using it to attest to the origin of questionable content. In other words, prior to an email being signed by the authenticating mechanism, checks must be made using appropriate means in order to determine whether the content to be signed conforms to a given set of guidelines, including, for example, not being spam and not containing any viruses.

Contrary to existing offerings, which are a packaged as products made up of a patchwork or independent technologies, Kryptiva believes that the primary property of any real-world solution to modern email problems is that it be provided as a set of coherently integrated services. Coherent integration entails that the functionality provided, be it tracking, encryption and/or authentication, does not require the management and deployment of separate technologies. The current practice of using, for example, one technology for encryption, say S/MIME, and another for authentication, say DKIM, must be avoided at all cost. Instead, what is needed is a technology that can provide all the required mechanisms for resolving email's contemporary shortcomings within a single, flexible framework.

In addition, the delivery of such integrated functionality should be as a set of services not as a set of products. Such integrated email security services are best suited for modern corporate networks since they provide a continuous, incremental and evolutionary path for corporate email security in sync with its users' needs and requirements. Granted, software products must be available to use the services, but these products must be freely available as part of the delivery of the services, in one form or another, for authorized users. As a result of such an approach, upgrades and additional feature enhancements do not require large capital expenditures, the latter often being subject to extensive planning and budgeting. Rather, upgrades and additional feature enhancements are available as gradual evolutions of existing service levels.

Modern corporate environments place substantial maintenance burdens on IT departments. In turn, IT personnel must ensure that the network infrastructure is resilient and flexible. As such, we believe that any email security system must be orthogonal to the network architecture where it is being integrated. Put simply, a best-of-breed email security system must not require any modification whatsoever to existing infrastructure; it must be infrastructure-independent. Only by adhering to such a design policy are seamless integration and graceful service failover possible.

Seamless integration means that adding the new services to a network should not require inserting new hardware as a gateway in between existing network connections. In fact, the added security services should simply coexist with other network services already available to locally-connected user stations and be available to users in a similar interactive fashion. This allows for maximizing past network investment by allowing gradual adoption within an organization. Therefore, IT departments are not faced with choosing between full deployment or no deployment at all. Instead, services can be gradually phased in to more and more users.

Seamless integration also means that existing servers and their configurations should not require any modification whatsoever for the addition of the new services. Neither should existing servers require any additional software nor incur any processing slowdown because of the new services. Instead, the new services should integrate coherently with existing servers and their services for providing users with additional functionality.

Graceful service failover means that should the email security services become unavailable then email can be transparently degraded to its insecure form without any downtime whatsoever.

Needless to say many products currently on the market fail to meet both these criteria. Mainly, there are an abundance of products which must be installed in between an organization's mail servers and the Internet. Because of their network placement, such products add yet another potential point of failure. And, as more and more products vie for being installed back-to-back in between mail servers and the Internet, IT departments unfortunately find themselves having to choose in between upgrading existing products to more feature-full products, therefore wiping out passed investments, or continuing to add more hardware at the network's periphery in the hopes that the latest addition will be the last. Either way, and in addition to suffering from the drawbacks mentioned earlier, because such products are placed in between critical connections, adding them entails downtime at installation and at any time significant servicing is required.

The management of user identities and access controls is the cornerstone of any corporate network. As such, while a slew of products on the market provide separate software for managing users' cryptographic identities, such as certificate management software and the likes, we believe that any security service must integrate with existing standard directory services without requiring IT staff to use additional interfaces and/or administer separate software components. Specifically, this means aiming for integrating with at least the most widely used directory services, namely LDAP. By doing so, all that is needed to configure the new security services is to fill-in the information required to contact existing LDAP servers for controlling user access.

Once set up, LDAP-integrated security services should use the existing directory services for checking whether users have access to the security services and, further, whether they are authorized to conduct given operations on secured emails. Referring back to the above key functionality requirements, this means that key users' operations on both outgoing and incoming secured emails are subject to their existing LDAP profile.

As senders, for example, users attempting to use the security services for their outgoing emails should first be authorized to use the services by checking, say, whether the password given to access the security services matches the one found in the LDAP directory. By doing so, this allows an organization to control, amongst other things, which users are authorized to sign outgoing emails on its behalf, and whether they are authorized to send encrypted material outside its premises.

Conversely, when receiving secured content, users' right to decrypt content should be exclusively controlled by the existing directory services. Therefore, there is no need for attributing and/or obtaining and managing per-user certificates. Instead, the decision for decrypting material sent to a user within an organization depends solely on their matching LDAP profile, say, for instance, by making sure that a user is indeed part of an email's recipient list before decryption is authorized.

Only by fully integrating with LDAP, instead of requiring a separate certificate management infrastructure, can new security services be cost-effective and scalable. Case-in-point, doing away with certificate management infrastructures, in favor of LDAP-centric security services access control, means that there is much less complexity for IT staff to manage and an easier work environment for users. Namely, there would be no need for burdensome security procedures such as securing keys, revoking keys, publishing certificates, interfacing with certificate authorities, etc. and, most importantly, no need for either users or IT staff to master the complexities of PKI.

While, in relatively small organizations, easy, unrestricted access to IT systems and data is usually not considered a problem by most users and IT staff, in any sizable organization there are stringent requirements for compartmentalizing access to critical information. Salaries, ongoing sales opportunities, legal proceedings, intellectual property, etc. are all assets to which access should be available only to those with a right to know. As such, while IT staff is critical to the day-to-day operation of any corporate network, it is detrimental for any organization that even the IT staff's access to sensitive email be kept in check.

Basically, we find that there is no reason why IT staff should be able to read everyone's emails unrestricted simply by virtue of having access to an organization's mail servers. Instead, functionality should be available, and every effort should be made, for allowing only the designated recipients of an email to read its actual content. Specifically, emails should be stored in an encrypted form on servers and require access to information stored on users' local data storage, say their PC's hard-disk or a portable storage media such as a USB drive, in order to read encrypted content.

Only by divorcing the storage of encrypted email from the ability to read it, and its attachments, "in clear text" is it possible to make sure that critical information remains accessible only to those authorized to access it. Such separation will not, of course, in and of itself put a stop to potential abuses. Nevertheless, it provides the ability for attentive users to be in control instead of having no choice as to whether their email is available in clear text on the corporate servers. In other words, while it may still be possible for a malicious IT staff member to access the CEO's inbox by retrieving the necessary decryption material from the CEO's PC and using it to read encrypted email stored on the company's server, this is much more elaborate to pull off, and, therefore, makes its illicit nature much easier to spot and, mostly importantly, to prevent than the common, innocuous case of the same IT staff member "accidentally" stumbling on the CEO's emails on the mail servers.

Probably one of the most irritating phenomenons due to the recent proliferation of email filtering products at corporate network perimeters is that attachments can now arbitrarily get dropped, often without notice. So while an important email eventually gets delivered, it may arrive without its attachments and both the sender and the recipient may be unaware of the fate of the dropped attachments. Therefore, as part of authenticating origin and content, it should be possible for senders to package encrypted emails so that attachments may not get dropped along the way by overzealous email firewalls, while still allowing automated verification of their email for conformance to set guidelines at any point of the email's transfer to its designated recipient.

Automated verification of conformance to set guidelines is only possible if the underlying mechanisms provided allow for both authenticating the source and certifying content, as described earlier. Without such a capability, there is no reason why administrators of email firewalls should trust encrypted content of incoming email. On the contrary, the ability to automatically verify that emails have already been pre-vetted for certain criteria, say like not containing either spam or viruses, actually allows for much faster filtering of incoming emails.

With regards to making attachments undroppable from a technical standpoint, then the only possibility is that they be removed at encryption time for being included in the email's body along with the original body in encrypted form. In transit, such an encrypted email would not appear to have any attachments, but would contain a large body. At the recipient's end, the attachments can be recreated and made accessible to the receiving user once the email is successfully decrypted. While we realize this runs counter-sense to established practice, this is the most effective fashion of making sure emails' integrity is preserved while in transit. Either they get delivered in their entirety or they don't get delivered at all, but in both cases the sender knows his email's status because he is able to track its delivery.

The low-hanging fruit of controlling users' access to secure content is to provide them with software with fixed, limited capabilities. In other words, the software used to access certain content is crippled but the user could use different software, or reverse-engineer the software originally provided, to gain unrestricted access to secure content. Products providing such user-control mechanisms are often marketed to senders with extravagant claims as to the products' abilities to control or monitor recipients' handling of content processed by said products. For example, senders are told their recipients may be capable of viewing encrypted content only, but not forward it on. Worse, senders of encrypted content are provided with functionality which seemingly allows them to control what happens to documents after they have been delivered to their designated recipients, say by allowing a sender to render a document "inaccessible" after a certain time. Such functionality consists of application-level security and provides nothing more than a false sense of security to senders.

At the most basic level, application-level security is flawed because it relies on attempting to control behavior by means of limiting software capabilities. In the case of controlling content after delivery, for example, there are a variety of ways in which recipients can circumvent application-level security. First, as mentioned earlier, recipients may reverse-engineer whatever mechanism is used to preclude them from controlling the content they received, or, more commonly, third-party developers may develop and distribute software to circumvent whatever user controls are built into a software and therefore render the advertised controls useless. Also, recipients can use any form of screenshot software or virtualization product to grab a snapshot of the current content being displayed and forward it on. Even more crude, recipients can simply take pictures of content being displayed on screen with a digital camera and spread those to unauthorized recipients. As another example of misleading application-level security, many products that claim to provide senders with the ability to monitor when their email was read and how much time was spent by recipients reading their email can easily be circumvented by bypassing the trigger mechanism allowing the product to operate as advertised. In sum, any security mechanism relying on application-level security is no security mechanism at all.

Therefore, any effective security functionality should be engineered in view of protocol-level security and no extravagant claims should be made about the security provided by the protocol. Such functionality entails that even if the source code of the software used by recipients to access secure content were available, then they wouldn't be able to gain access to content not originally made available to them. Furthermore, no claims should be made as to any protocol's ability to control content once it's been rightfully accessed by designated recipients. A truly secure protocol will, by definition, very effectively provide a fixed set of functionalities and ensure that the underlying behavior is strictly enforced regardless of the software being used to implement the protocol.

Possibly one of the greatest mistakes made early on by the promoters of public key cryptography was the emphasis put on explaining how such a cryptosystem worked and how safe it was because of the use of separate public and private keys. While public key cryptography does indeed provide a high level of security and certainly does mark an improvement over symmetric key cryptography, where parties needed to agree to a secret key beforehand for all to use, it has many shortcomings.

There is, in fact, little in any user's day-to-day routine that resembles public key cryptography, unlike usernames and passwords, for example, which are commonly understood by all users -- though it's worth noting that, simple as the concept may be, even the most sophisticated users routinely have a hard time remembering passwords and can rarely be made to use different passwords for different systems or services. But the problems don't stop there. Because even when users are made to understand the basics of public key cryptography, they soon learn they also need to become familiar with even more complicated concepts such as certificate authorities, webs of trust, certificate revocation lists, key signing, etc. At this point in time, public key cryptosystems have been around long enough that it's fair to say that the record has shown that mainstream users are simply unwilling to put up with such complexity.

Put simply, what is needed from a new set of email security services is that they provide the same advantages of public key cryptography without any of its disadvantages. To achieve this goal, one of the first requirements is that the new services be built in a fashion where key pairs are disposable. We find that there is no justification for investing large amounts of resources in securing a given private key when the loss of that key will immediately result in that investment being wiped out. Instead, keys should be easily replaceable, their replacement should not lead to the loss of any previously-encrypted content and, most importantly, the publication of a private key, be it voluntary or not, should have limited and deterministic effects. Furthermore, keys should be assigned and managed at an organization level, not on an individual basis. As such, no user in an organization should need to have to manage, or even require access to, any private key.

In addition, in order to be truly user friendly, email security services that rely on public key cryptography should be designed such that the details of the algorithms, key sharing and validation and the likes be hidden away in lower levels of the software. The users' actions may indeed trigger public key cryptography mechanisms, but none of the intricacies of these operations should be exposed to the user. Still, this type of abstraction should not result in any decreased level of security. On the contrary, email exchanges in their entirety must have their security reinforced by making it simpler for users to integrate security functionality in their daily routine while communicating to users anomalies and problems in a fashion which they can readily relate to.

Only by designing security services with such goals in mind does it become realistic to entertain providing every user in an organization access to email encryption.

One of the ways in which some product manufacturers have tried to circumvent the shortcomings of traditional email encryption technologies is to provide intermediate storage of secure content for delivery to recipients. This is often sold as either part of a perimeter appliance which automatically stores outgoing secure messages for delivery to designated recipients or as special plugins to email applications which contact a designated secure storage website to store a critical email to be delivered to a recipient. Either way, the recipient is provided with an email notification to the effect that they must follow a link in order to access a secure email stored for them on a web server.

Apart from the serious security issues arising from redirecting recipients to websites, as discussed elsewhere in this section, storing secure content on publicly-accessible servers brings with it inherent, unbounded risks. Simply put, by allowing the storage of secure content on a web server, organizations must blindly trust those that packaged and developed the entire stack of software running on said server for it not containing any flaws permitting unauthorized access to the stored information. Unfortunately, experience has shown many times over that even some of the most widely tested software stacks can contain security holes which have remained "officially" undetected for years; that is to say that it is possible that the security holes may have been known to certain people or groups for an indefinite amount of time prior to their being publicly recognized and patched. We therefore believe that content should not be left on publicly-accessible web servers for attackers to repeatedly attempt to break through said servers' defenses or exploit security holes. Instead, the cryptographic protocol used for securing email content should not require any centralized storage of secure emails.

The problems of active storage of secure emails are made worse when storage is effected at a third party's facilities. In that case, organizations have no way of either auditing or controlling access to the storage media of the designated servers. While, in such a setup, the third party may provide assurances to organizations attesting its good faith and abilities, it remains that organizations are thereby blindly trusting an outside party with content which may be detrimental to their operations. We strongly believe that no organization should have to entrust critical content to any third party for temporarily storing it until a recipient retrieves it. As stated earlier, the cryptographic protocol used must allow for emails to arrive in encrypted form as-is to the designated recipient; the latter having, or being provided with, the means to decrypt and read the email and store it safely. Under no condition is it acceptable that third parties be trusted with secure content which they would not otherwise have had access to.

Making statements with regards to user interfaces can easily become an exercise in futility as claims of user-friendliness abound. However, we strongly believe in key design criteria with regards to the creation of user interfaces for security.

First, a smartly-designed security interface should not permit the user to accidentally break the system's security because of a misunderstanding on his part. Instead, every effort should be made to provide timely information to the user in order to allow for him to make the best possible decision and, in the case where user choices may represent a potential security problem, provide the user with appropriate warning in order to allow appropriate reaction.

As a corollary, the user interface must be designed in order to allow users to benefit from all the security solution's capabilities with as little perturbation to their daily routine usage of their email software as possible. Essentially, the goal must be to remain as visually unintrusive as possible while judiciously positioning important menus and displaying appropriate dialog boxes in a timely fashion.

Based on these criteria, and as we mentioned earlier, it is our belief that the use of external websites for access and display of secure email content is a poor design choice. In addition to the arguments presented above, it is noteworthy that the sending of emails to recipients with links to familiar-looking websites is a remarkably well known vector of attack to lure unsuspecting users into providing confidential information. There is, in fact, no difference from the user experience standpoint in between receiving a "secure" email redirecting to a website and receiving a phishing attempt. Both require the user to go to an online website and provide information. And while one may be tempted to draw a line between the type of information requested on the website where the user is redirected, it should be pointed out that most users are unfortunately not as sophisticated in terms of security precautions. Research has shown that even knowledgeable users have a difficult time separating legitimate from illegitimate websites. Therefore, once users are taught to trust a certain user experience, they are very likely to be mislead by similar correspondence inviting them to enter information on familiar-looking websites. Ultimately, therefore, the only interface which users should be reinforced to trust is their existing email client application.